[leva]

В сто пятидесятый раз попал в туже ситуацию и решил разобраться в вопросе.
Итак, изначальная постановка Wamr была: как правильно реализовать серверный обработчик (плюс который нормально будет работать в пакете) с параметрами, изменяемыми в диалоге. Само собой этот параметр будет в списке тех, которые сохраняются в pack() и поэтому если мы этот параметр parm-методом зададим он перетрётся старым значением.

Есть предложение db писать в таких случаях в main():
.getLast()
.parmXXX(...)
.saveLast()

Я так тоже делал, но такой метод мне не нравится, так как во-первых, сохраняет уже сразу после вызова, даже если мы отменим выполнение в диалоге и во-вторых, если класс сделан с запросом на QueryRun (который сохраняется в pack()), то нужно уже на этом этапе как-то его инициализировать.

sukhanchik предложил просто такие параметры не "распаковывать" если они не пусты, признав далее извращенность такого решения. И далее дискуссия ушла в обсуждение Enum-ов, чего касаться я вообще не хочу.

Собственно я предлагаю такой вариант:
1. В classDeclaration добавить макрос со списком параметров, которые будут меняться в диалоге, например:

    #localmacro.ParamsList
        param1,
        param2
    #endmacro

2. В unpack() сохранять эти значения в контейнер и в случае, если метод был вызван для загрузки старых значений (определяется методом this.inGetSaveLast()) восстанавливать их, например:

public boolean unpack(container packedClass)
{
    Version version     = runbase::getVersion(packedClass);
    container   params = [#ParamsList];

    switch (version)
    {
        case #CurrentVersion:
            [version,#CurrentList] = packedClass;
            if (this.inGetSaveLast())
                [#ParamsList] = params;
            break;
        default:
            return false;
    }

    return true;
}

Таким образом, при загрузке значений клиентской копией и при создании объекта пакетного задания (в этих случаях inGetSaveLast = false) загрузится всё из упакованного контейнера, а случае запуска из меню с определёнными параметрами эти параметры не перетрутся.
Единственное надо проверить, чтобы на всех версиях аксапты параметр inGetSaveLast вёл себя одинаково. Ну и в минусы можно записать то, что этот список нужно не забывать пополнять по мере доработки класса (версионность тут вроде не нужна).

Подводных камней вроде не вижу. Что скажете?