|
16.01.2012, 17:13 | #1 |
Участник
|
Ошибка Microsoft
Добрый день
При отмене закрытия склада в некоторой специфической ситуации (думаю в данном случае не важно в какой) вдруг перестала перестали корреспондитоваться постинги в LedgerTrans. После разбирательства показалось станным, что в методе LedgerVoucherTransList.first() не меняется значение refId_RU. Вставка оператора refId_RU = ledgerTransObject ? transIterator.key() : 0; исправила ситуацию. (Ax3, Ax4, Ax5 - все аналогично). Судя по всему ошибка локализации |
|
|
За это сообщение автора поблагодарили: Logger (3), b_nosoff (2). |
16.01.2012, 17:18 | #2 |
Участник
|
Можете подробнее указать место ?
|
|
17.01.2012, 10:08 | #3 |
Читатель
|
GEEU
Там мало того, что при выборке первого элемента не инициализируется refId, так еще и в LedgerVoucherTransList.next() происходит неявное приведение str к int А сработает эта мина в том случае, если вдруг кто захочет еще разок пройтись по этому итератору и вызовет first()...
|
|
|
За это сообщение автора поблагодарили: NNB (1). |
17.01.2012, 11:07 | #4 |
Участник
|
По просьбе Logger:
Класс LedgerVoucherTransList метод first() В нашем случае получилась явно неправильная корреспонденция Надо выбрать время и посмотреь что было в других ситуациях Я так понимаю что Microsoft готовит следующую локализациют (набирает людей). Господа исправьте пожалуйста |
|
17.01.2012, 12:11 | #5 |
Участник
|
Прежде, чем бросаться громкими заявлениями, неплохо бы посмотреть а для чего это значение вообще используется. Насколько я вижу, цикл first()...next() использует refId_RU только для индикатора прогресса. Просто, чтобы показать, что процесс идет. Так что, без разницы, что там будет за значение. Разумеется, если Вы сами не прикрутили какой-то функционал к этой переменной именно в цикле first()..next().
Так что, очень даже имеет смысл пояснить о какой такой "специфической ситуации" идет речь. Т.е. где-это Вам потребовалось использовать значение refId_RU иначе чем индикатор прогресса.
__________________
- Может, я как-то неправильно живу?! - Отчего же? Правильно. Только зря... |
|
17.01.2012, 12:29 | #6 |
Читатель
|
LedgerVoucherObject.postRoundingDifferencesPerDate()
X++: ledgerBondServer.findBondTransObject(ledgerTransList.itemRefId_RU()) |
|
17.01.2012, 13:41 | #7 |
Участник
|
Что бы на бросаться громкими фразами предлагаю заинтересовавшихся запустить поиск refId_RU по классам LedgerVoucherObject, LedgerVoucherTransList, LedgerBondServer_RU, LedgerBoundTransList_RU, LedgerBondClient_RU, LedgerBondTransObject_RU (для начала хватит) и сделать собственные выводы
|
|
17.01.2012, 14:58 | #8 |
Участник
|
Цитата:
Цитата:
Сообщение от NNB
Что бы на бросаться громкими фразами предлагаю заинтересовавшихся запустить поиск refId_RU по классам LedgerVoucherObject, LedgerVoucherTransList, LedgerBondServer_RU, LedgerBoundTransList_RU, LedgerBondClient_RU, LedgerBondTransObject_RU (для начала хватит) и сделать собственные выводы
__________________
- Может, я как-то неправильно живу?! - Отчего же? Правильно. Только зря... Последний раз редактировалось Владимир Максимов; 17.01.2012 в 15:03. |
|
17.01.2012, 16:02 | #9 |
Читатель
|
Цитата:
А ItemRefId не что иное, как порядковый номер проводки в списке ваучера. И значение его должно быть вполне предсказуемо. Я вас убедил, или вы все еще рассматриваете локализацию LedgerVoucherTransList как образцовую? |
|
17.01.2012, 16:52 | #10 |
Участник
|
Цитата:
Сообщение от b_nosoff
Вот на таких домыслах система и превращается в неуправляемого монстра.
А ItemRefId не что иное, как порядковый номер проводки в списке ваучера. И значение его должно быть вполне предсказуемо. Я вас убедил, или вы все еще рассматриваете локализацию LedgerVoucherTransList как образцовую? Я же говорю, "тщательнЕе" надо. Более внимательно изучать код. То, что это идентификатор и так понятно. Но в данном случае есть проблема с идентификаторами? Насколько я вижу, методы first() и next() вообще не имеют никакого отношения к идентификации. Они существуют "паралельно" с методом add(), который как раз и относится к идентификации. Как образцовую, я реализацию LedgerVoucherTransList естессвенно, не рассматриваю. Именно в силу не очевидности кода. Существование в одном и том же классе неких "паралельных" логических структур.
__________________
- Может, я как-то неправильно живу?! - Отчего же? Правильно. Только зря... |
|
17.01.2012, 17:23 | #11 |
Читатель
|
Ну и ладно. Может кого другого убедил.
Просто, в качестве заключения - я полностью уверен в том, что это была попытка добавить к итератору функционал получения индекса текущего элемента. Duck typing, знаете ли... |
|
17.01.2012, 17:53 | #12 |
Участник
|
Цитата:
В данном случае я не уверен в том, что методы first()..next() имеют какое-либо отношение к этому самому индексу текущего элемента. Неужели с Ax3.0 никто не налетал на эти грабли? Ведь очевидно же, что метод next() противоречит методу add(). Метод next() на последнем элементе даст значение 1. Метод first() на первом элементе даст значение либо 1 (после последнего next()), либо elements()+1 (после add()). Явно же, что после использования методов first() и next() метод itemRefId_RU() возвращают какую-то ерунду, а не идентификаторы. Просто некий счетчик, не имеющий вообще никакого отношения к идентификаторам. Вот в эту ловушку NNB и попал. Он использовал first() .. next() как способ получения идентификатора. А в данном классе это не так.
__________________
- Может, я как-то неправильно живу?! - Отчего же? Правильно. Только зря... |
|
17.01.2012, 15:48 | #13 |
Участник
|
Могу
Только завтра - сегодня некогда |
|
17.01.2012, 18:16 | #14 |
Moderator
|
После использования методов first() и next(), метод itemRefId_ru() возвращает как раз не ерунду. Достаточно посмотреть на код из LedgerVoucherObject.Post().
Просто ошибка эта может стрельнуть только в случае, если происходит повторный вызов first() на полпути, так сказать. Типа начали итерацию, поитерировали, а потом не дожидаясь исчерпания итератора (возвращения значения false методом next()), попробовали вызвать first(). В этом случае, следующий вызов itemRefId_ru() вернет значение рассинхронизированное с методом item(). Однако, я в коде стандартных классов, такого места не нашел. Везде вызывается first() и потом итерируется до тех пор, пока next() не вернет false, сбросив, таким образом, refId_ru в исходное нулевое значение. Так что на первый взгляд:
|
|
17.01.2012, 18:51 | #15 |
Участник
|
Цитата:
Т.е., по большому счету, именно что "ерунду" возвращает. Некое число, не имеющее никакого отношения к идентификации. Просто некая возрастающая последовательность чисел. Может, там просто счетчик надо было поставить ============================= И, кстати, насчет идентификации... На всякий случай напомню, что MAP автоматически упорядочивает список по значению ключа. Но порядок следования чисел в символьном представлении отличается от порядка следования в числовом представлении. Так что, и с этой стороны данный класс "не подарок" И опять же, явно противоречит использованию first() и next(). Не та последовательность перебора элементов. Отличная от последовательности создания элементов. X++: static void Job_Test(Args _args) { MAP transObject = new Map(Types::String, Types::Integer); MapIterator transIterator; ; transObject.insert('2', 1); transObject.insert('11', 1); transIterator = new MapIterator(transObject); while (transIterator.more()) { info(transIterator.key()); // Сначала будет "11", потом "2" transIterator.next(); } } Я просто не вижу зачем вообще нужно значение refId_RU при переборе элементов через first() и next(). Не вижу его использование как идентификатора именно после этих методов. После метода add() - есть использование. А после first(), next() - нет.
__________________
- Может, я как-то неправильно живу?! - Отчего же? Правильно. Только зря... |
|
|
За это сообщение автора поблагодарили: b_nosoff (1). |
17.01.2012, 19:08 | #16 |
Читатель
|
блиин, во это подстава, так подстава я даже не обратил внимания. Это что ж получается, если мы этим итератором начнем выбирать проводки из ваучера с количеством строк больше 10, то на третьем шаге получим десятую строку и т.д. И ведь это уже не локализаторы...
|
|
17.01.2012, 19:25 | #17 |
Участник
|
Цитата:
__________________
-Ты в гномиков веришь? -Нет. -А они в тебя верят, смотри, не подведи их. |
|
17.01.2012, 19:33 | #18 |
Moderator
|
Цитата:
Д 10.01 К 60.01 200 руб Д 10.02 К 60.01 300 руб То я могу без малейшего ущерба поменять их порядок на Д 10.02 К 60.01 300 руб Д 10.01 К 60.01 200 руб Так что порядок итерирования тут не важен в принципе... |
|
18.01.2012, 09:57 | #19 |
Читатель
|
В данном конкретном случае - ни на что. Но это не отменяет ожидания последовательности от системы. Нефиг было добавлять в конце названия объекта List.
Уж если собирались сделать выборку элементов в порядке добавления (а здесь, я уверен, именно этот случай), то извольте реализовать как следует. Иначе могли бы и не заморачиваться с Map, а тупо List использовать (что, в принципе, как раз бы и помогло достичь указанной цели). Да тут-то как раз все понятно, просто внутреннее значение начинается с нуля, а возвращаемое параметром - с единицы |
|
|
За это сообщение автора поблагодарили: Владимир Максимов (2). |
17.01.2012, 19:28 | #20 |
Moderator
|
Сохраненное значение возвращается методом ledgerVoucherObject.lastRefid_ru(). Который, в свою очередь, активно вызывается и используется методом ledgerBondServer.splitTrans() Фактически этот метод вынимает из lastRefId идентификатор последнего обрабатываемого постинга, который сейчас разносится. Метод splitTrans(), как раз таки вызывается по цепочке ledgerVoucherObject.Post()->LedgerVoucherTransObject.post()->LedgerVoucher.postGroup()->ledgerBondServer.splitTrans(). То есть - это как раз позволяет классу корреспонденции добраться до контекста верхнего уровня и понять чего же это мы сейчас разбиваем в списке проводок (в случае детального постинга - без группировки сходных разносок).
Последний раз редактировалось fed; 17.01.2012 в 19:33. |
|
|
|