Kashperuk Ivan: Dynamics AX TutorialsHello, everyone.I was goi...

[petr]

To mazzy:
Я выступаю за разграничение скажем так ответственности. Если необходимо запоминать выбор пользователя, и воможно из других участков программы проверять проставлены ли эти галочки (т.е. промаркирована ли та или иная запись или нет), то конечно лучше использовать таблицу из AOT. И эти единственный выход.

Но если в определенный форме, необходимо дать пользователю возможность отметить несколько записей, то мне кажется вариант Ивана (и он, кстати не из головы его придумал, а такой подход используеся и в самой Аксапте) то правильный.

Во всяком случае он не использует временные таблицы для хранения отмеченных записей, и не добавляет новое поле (для галочки) в саму таблицу и подобные ошибки. Сам из когда то допускал, и не хочу чтобы их повторяли другие.

[mazzy]

Цитата:

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

А почему? Форма на клиенте, set на клиенте. Я думаю пока пользователь выбирает записи то все выполняется на клиенте, т.е. заполняется set и вызовов между клиетом и сервером не будет.

Тогда set живет на клиенте.
Этот случай я уже критиковал Kashperuk Ivan: Dynamics AX TutorialsHello, everyone.I was goi...

Цитата:

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

А вообще хорошо, что мы подняли этот вопрос. Такая необходимость (дать возможность пользователю отметить несколько записей из всего грида) возникает время от времени, а я пока нигде не встречал готорого паттерна для решения такой задачи.

Здесь уже давали ссылку
http://www.axaptapedia.com/Multiple_grid_selections

Стандартный паттерн называется multiSelect.
Он даже имеет свойство для menuitem.
Обрабатывается ядром на клиенте.

Цитата:

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

Но если в определенный форме, необходимо дать пользователю возможность отметить несколько записей, то мне кажется вариант Ивана (и он, кстати не из головы его придумал, а такой подход используеся и в самой Аксапте) то правильный.

Ok. Попробуйте.
Но сначала таки прочитайте про multiSelect.

Цитата:

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

Во всяком случае он не использует временные таблицы для хранения отмеченных записей, и не добавляет новое поле (для галочки) в саму таблицу и подобные ошибки. Сам из когда то допускал, и не хочу чтобы их повторяли другие.

1. Почему вы считаете временную таблицу ошибкой?
2. галочка отдельным полем есть в сводном планировании. Галочка отдельным полем очень даже подходящее решение, если для всех пользователей набор галочек общий

Еще раз - если речь идет о НЕСКОЛЬКИХ записях, то не надо ничего придумывать и программировать классы - просто обрабатывайте стандартное выделение нескольких строк. (Кстати, этот способ не требует программирования, если пользователь захочет выделить все строки)

Если же речь идет о массовой расстановке галочек, то галочки нельзя хранить в свопе клиента.
Не стоит делать массовые галочки, по которым не работает фильтр и сортировка.
Не стоит делать массовые галочки, которые нельзя обработать на SQL-запросом.
Не стоит делать массовые галочки, которые требуют большого траффика между клиентом и сервером.

[EVGL]

Цитата:

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

Стандартный паттерн называется multiSelect.
Он даже имеет свойство для menuitem.
Обрабатывается ядром на клиенте.

Обрабатывается программистом в ::main()

Мне кажется, не стоит устраивать тут религиозные войны. Попробую обобщить:
+) Вариант с "крестиком" позволяет пользователю подумать. Он не мучается, придерживая Ctrl.
-) Вариант с "крестиком" требует написания большего количества кода

+) Вариант с multiSelect хорош, когда выделяемых строк мало
-) Вариант с multiSelect медленнее, чем "крестик", поскольку работает не с одной переменной, а с целым буфером записи из datasource, хотя эффект, наверное, исчезающе мал

+) Вариант крестика с Set хорош тем, что его проще запаковать и передать на сервер

-) Вариант с временной таблицей хорош тогда, когда таблица имеет композитный ключ, а индекса по RecId нет. Для Set пришлось бы строить какой-то hashStr, а потом его еще и разбирать.

[kashperuk]

Еще информация для размышлений:

Вот job для экспериментов

static void tutorial_Job_getMemAlloc(Args _args)
{
    HeapCheck heapHeck = new HeapCheck();
    int allocFirst;
    Set set1;
    Set set2;
    Set set3;
    int i;
    timeOfDay time1;
    TmpInventTable tmpIT;
    Counter recIdCount;
    ;
    recIdCount = 40000;
    allocFirst = heapHeck.bytesAllocated();
    info(strfmt("%1 - До заполнения", allocFirst));

    time1 = timeNow();
    set1 = new Set(Types::Integer);
    for (i = 1; i <= recIdCount; i++)
        set1.add(i);
    allocFirst = heapHeck.bytesAllocated();
    info(strfmt("%1 - %2сек - заполнили Set(Types::Integer)", allocFirst, timeNow() - time1));

    time1 = timeNow();
    set1 = new Set(Types::String);
    for (i = 1; i <= recIdCount; i++)
        set1.add(strFmt("Item%1", i));
    allocFirst = heapHeck.bytesAllocated();
    info(strfmt("%1 - %2сек - заполнили Set(Types::String)", allocFirst, timeNow() - time1));

    time1 = timeNow();
    for (i = 1; i <= recIdCount; i++)
    {
        tmpIT.ItemId = strFmt("Item%1", i);
        tmpIT.insert();
    }
    allocFirst = heapHeck.bytesAllocated();
    info(strfmt("%1 - %2сек - заполнили временную таблицу из одного поля - ItemId", allocFirst, timeNow() - time1));
}

Вот мои результаты: (40000 элементов)
28 939 792 - До заполнения
30 413 632 - 1сек - заполнили Set(Types::Integer)
30 401 280 - 1сек - заполнили Set(Types::String)
32 763 840 - 13сек - заполнили временную таблицу из одного поля - ItemId

Обращу внимание на время, требуемое для заполнения временной таблицы таким большим кол-вом записей. SET заполняется почти мгновенно. (правда у других проверяющих время заполнения меньше для таблицы - видимо это связано с тем, что винт у меня на ноутбуке не очень быстрый)

Оговорка:
Результаты по выделению памяти приблизительные, так как

Цитата:

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

Память выделяется кусками. Т.е. если объект в памяти занимает меньше места, чем свободно - то выделение не происходит, а размещается в свободном куске

Для небольшого числа записей разница настолько мала, что измерить не удалось

Анализ результатов (краткий):
первые два заполнения - 2 Мб выделилось приблизительно, (на двоих)
на табличку - еще столько же где-то.

Учитывая это и время заполнения, использование временной таблицы ставится под вопрос.
+ большой конечно, что можно ее потом использовать в запросах. Правда и в этом нужно быть осторожным, так как нужно учитывать, где формировалась эта таблица (первая запись).

У кого какие соображения?