Ошибка Microsoft

[Владимир Максимов]

Цитата:

Сообщение от fed

После использования методов first() и next(), метод itemRefId_ru() возвращает как раз не ерунду. Достаточно посмотреть на код из LedgerVoucherObject.Post().

А дальше? Ну, получили значение lastRefId и как оно дальше было использовано? В классе LedgerVoucherObject - никак. Так какая разница, что именно в этой переменной записано?

Т.е., по большому счету, именно что "ерунду" возвращает. Некое число, не имеющее никакого отношения к идентификации. Просто некая возрастающая последовательность чисел. Может, там просто счетчик надо было поставить

=============================
И, кстати, насчет идентификации...

На всякий случай напомню, что MAP автоматически упорядочивает список по значению ключа. Но порядок следования чисел в символьном представлении отличается от порядка следования в числовом представлении.

Так что, и с этой стороны данный класс "не подарок" И опять же, явно противоречит использованию first() и next(). Не та последовательность перебора элементов. Отличная от последовательности создания элементов.

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]

Цитата:

Сообщение от Владимир Максимов

И, кстати, насчет идентификации...

На всякий случай напомню, что MAP автоматически упорядочивает список по значению ключа.

блиин, во это подстава, так подстава я даже не обратил внимания. Это что ж получается, если мы этим итератором начнем выбирать проводки из ваучера с количеством строк больше 10, то на третьем шаге получим десятую строку и т.д. И ведь это уже не локализаторы...

[Pustik]

Цитата:

Сообщение от b_nosoff

блиин, во это подстава, так подстава я даже не обратил внимания. Это что ж получается, если мы этим итератором начнем выбирать проводки из ваучера с количеством строк больше 10, то на третьем шаге получим десятую строку и т.д. И ведь это уже не локализаторы...

Детально обсуждалось здесь Не корректная сортировка в Map-e и Set-е. AX2009 RU5

[fed]

Цитата:

Сообщение от b_nosoff

блиин, во это подстава, так подстава я даже не обратил внимания. Это что ж получается, если мы этим итератором начнем выбирать проводки из ваучера с количеством строк больше 10, то на третьем шаге получим десятую строку и т.д. И ведь это уже не локализаторы...

А на что влияет порядок проводок в ГК ? Ну то есть - если у меня в ваучере две проводки:
Д 10.01 К 60.01 200 руб
Д 10.02 К 60.01 300 руб
То я могу без малейшего ущерба поменять их порядок на
Д 10.02 К 60.01 300 руб
Д 10.01 К 60.01 200 руб

Так что порядок итерирования тут не важен в принципе...

[b_nosoff]

Цитата:

Сообщение от fed

А на что влияет порядок проводок в ГК ?

В данном конкретном случае - ни на что. Но это не отменяет ожидания последовательности от системы. Нефиг было добавлять в конце названия объекта List.
Уж если собирались сделать выборку элементов в порядке добавления (а здесь, я уверен, именно этот случай), то извольте реализовать как следует. Иначе могли бы и не заморачиваться с Map, а тупо List использовать (что, в принципе, как раз бы и помогло достичь указанной цели).

Цитата:

Сообщение от Владимир Максимов

Что-то здесь не правильно...

Да тут-то как раз все понятно, просто внутреннее значение начинается с нуля, а возвращаемое параметром - с единицы

[fed]

Цитата:

Сообщение от Владимир Максимов

А дальше? Ну, получили значение lastRefId и как оно дальше было использовано? В классе LedgerVoucherObject - никак. Так какая разница, что именно в этой переменной записано?

Сохраненное значение возвращается методом ledgerVoucherObject.lastRefid_ru(). Который, в свою очередь, активно вызывается и используется методом ledgerBondServer.splitTrans() Фактически этот метод вынимает из lastRefId идентификатор последнего обрабатываемого постинга, который сейчас разносится. Метод splitTrans(), как раз таки вызывается по цепочке ledgerVoucherObject.Post()->LedgerVoucherTransObject.post()->LedgerVoucher.postGroup()->ledgerBondServer.splitTrans(). То есть - это как раз позволяет классу корреспонденции добраться до контекста верхнего уровня и понять чего же это мы сейчас разбиваем в списке проводок (в случае детального постинга - без группировки сходных разносок).

[Владимир Максимов]

Цитата:

Сообщение от fed

Метод splitTrans(), как раз таки вызывается по цепочке ledgerVoucherObject.Post()->LedgerVoucherTransObject.post()->LedgerVoucher.postGroup()->ledgerBondServer.splitTrans().

Ну, я тут запутался чей именно LedgerVoucherTransList используется для получения этой ссылки. Вроде бы, используется объект, созданный LedgerVoucher, а вовсе не ledgerVoucherObject. Хотя, тут столько взаимных ссылок, что не удивлюсь, если это один и тот же объект.

Однако, проблема не в этом. Метод LedgerVoucherTransList.itemRefId_RU() возвращает значение refId_RU + 1. В смысле, на 1 больше, чем значение переменной refId_RU. В методе next() этой переменной присваивается значение идентификатора текущего элемента. Значит, в методе ledgerBondServer.splitTrans() идет сравнение не с текущим идентификатором, а со следующим? Что-то здесь не правильно...