Ошибка в методах unpack pack

[Arahnid]

У меня в диалоге 2 даты: fromdate todate.

При первом открытии формы диалога все хорошо, а при последующих

PHP код:

Ошибка времени выполнения. : Неправильные типы аргументов в операции присвоения значения переменной.
Трассировка стека:
\Reports\Cat_IASData\Methods\unpack - line 9
\Classes\SysReportRun\_unpack - line 9
\Classes\RunbaseReportStd\unpack - line 24
\Classes\xSysLastValue\getLast - line 16
\Classes\RunBase\getLast - line 9
\Classes\RunBaseBatch\getLast - line 3
\Classes\RunbaseReportStd\getLast - line 6
\Classes\RunBase\promptPrim - line 10
\Classes\RunBase\prompt - line 13
\Classes\RunBaseBatch\prompt - line 3
\Classes\RunBaseReport\prompt - line 13
\Classes\SysReportRun\run - line 6 


Убираю одну дату из окна диалога и программа работает с методами. В чем ошибка?

[George Nordic]

Тулбар-Настройка-Использование данных - сбросить.

Если не помогает, тогда выложите ваш класс.

С Уважением,
Георгий

[mazzy]

Цитата:

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

У меня в диалоге 2 даты: fromdate todate.

При первом открытии формы диалога все хорошо, а при последующих

При любом изменении списка сохраняемых значений, меняйте номер версии.
В unpack по умолчанию распаковывывается только текущая версия (вы можете добавить код для распаковки предыдущих).

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

В качестве обходного решения - стирайте сохраненные значения.
В качестве правильного решения - всегда изменяйте номер текущей версии при любом изменении списка.

[Russland]

Дополню от себя

Цитата:

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

Такое часто происходит, когда ведётся модификация класса (формы, etc.) и параллельно его использование (тестирование, например)

Цитата:

В качестве обходного решения - стирайте сохраненные значения

В этом случае помогает вручную удаление строки из таблицы, где хранятся упакованные значения. Это sysLastValue таблица.

Резюмируя, вот мой вам совет:
Всякий раз после модификации объекта, использующего unpack pack, возьмите за правило уничтожать записи в таблице sysLastValue (критерий: те строки, что "отвечают" за данный объект). Причём удалять надо строки по всем пользователям.

Данное решение я рассматриваю не как обходное, а как основное. Как правило хорошего тона, я бы сказал. Речь в данном случае идёт о цепочке:
пользователь поработал -> программист изменил код -> пользователь поработал -> .... ->

[mazzy]

Цитата:

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

Данное решение я рассматриваю не как обходное, а как основное.

Нет, конечно.
Меняйте номер версии и не нужно будет заниматься хакерством.

[Russland]

Да какое же это хакерство
Пусть меняет номер версии
но не забывает что делать это надо каждый раз когда покапался с пакованными параметрами.
Менял я версии, но почему-то сложилось мнение, что изменение версии не всегда работает стабильно (а именно, приводит к нужному результату).
Хотя давно это было, когда только начинал работать с Аксаптой. Поэтому и сложилось, наверное, такое мнение. Вероятно эта "нестабильность" была связана с тем что забывал перекомпилировать весь класс после изменений в ClassDeclaration.
Значитъ последовательность обязательных действий такова:

1. Изменить номер версии
2. Перекомпилировать весь класс (не F5 в окне ClassDeclaration) а из АОТ

[Russland]

Хотя удаляя sysLastValue на душе спокойней
Точно знаешь что параметры сброшены

[TasmanianDevil]

Быть может уже кто-нибудь сделал подобное, но рискну выложить ...

В RunBase добавляем метод

boolean checkContainmentTypes(container a, container b)
{
    int i;

    if(conlen(a) != conlen(b)) return false;

    for(i = 1;i<=conlen(a);i++)
    {
        if(typeof(conpeek(a,i)) != typeof(conpeek(b,i))) return false;
    }

    return true;
}

pack() наследника RunBase приобретает вид

public container pack()
{
    return [#list];
}

unpack() наследника RunBase приобретает вид

public boolean unpack(container packedClass)
{
    if(this.checkContainmentTypes([#list], packedClass))
        [#list] = packedClass;
    else 
        info(@'Сохраненный набор параметров для данного объекта не совпал по структуре с требуемым - значения восстановлены по умолчанию.');

    this.init();

    return true;
}

Не болит голова о версиях контейнера параметров - теперь версии никому никуда не уперлись.
Не болит голова о мусоре в SysLastValue - его просто не будет, ибо перезатрется .
Не болит голова о необходимости чистить SysLastValue - ибо просто не от чего его чистить.

P.S. И никакого хакерства и нелепых телодвижений по чистке всякого от всякого
P.P.S. И эцилоп не будет бить по ночам ... никогда ...

[tourist]

Цитата:

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

Быть может уже кто-нибудь сделал подобное, но рискну выложить ...

В RunBase добавляем метод

boolean checkContainmentTypes(container a, container b)
{
    int i;

    if(conlen(a) != conlen(b)) return false;

    for(i = 1;i<=conlen(a);i++)
    {
        if(typeof(conpeek(a,i)) != typeof(conpeek(b,i))) return false;
    }

    return true;
}

pack() наследника RunBase приобретает вид

public container pack()
{
    return [#list];
}

unpack() наследника RunBase приобретает вид

public boolean unpack(container packedClass)
{
    if(this.checkContainmentTypes([#list], packedClass))
        [#list] = packedClass;
    else 
        info(@'Сохраненный набор параметров для данного объекта не совпал по структуре с требуемым - значения восстановлены по умолчанию.');

    this.init();

    return true;
}

Не болит голова о версиях контейнера параметров - теперь версии никому никуда не уперлись.
Не болит голова о мусоре в SysLastValue - его просто не будет, ибо перезатрется .
Не болит голова о необходимости чистить SysLastValue - ибо просто не от чего его чистить.

P.S. И никакого хакерства и нелепых телодвижений по чистке всякого от всякого
P.P.S. И эцилоп не будет бить по ночам ... никогда ...

Небольшой нюанс: такая проверка не спасет, если пакуется query:

public container pack()
{
  return [#currentVersion, #currentList, this.queryRun.pack()]
}

, в этом случае version все равно придется менять, если были изменения в запросе.

[TasmanianDevil]

Цитата:

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

Небольшой нюанс: такая проверка не спасет, если пакуется query:

В цикле проверки, в случае если оба i-ых элемента окажутся контейнерами, добавить рекурсивный вызов функции проверки по этим элементам.
Запакованный запрос -контейнер из одного элемента типа BLOB, его трудно будет спутать с чем-то другим .

[ZVV]

Цитата:

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

В цикле проверки, в случае если оба i-ых элемента окажутся контейнерами, добавить рекурсивный вызов функции проверки по этим элементам.
Запакованный запрос -контейнер из одного элемента типа BLOB, его трудно будет спутать с чем-то другим .

Имелось ввиду, что если вы изменили в классе Кверю, а потом при запуске "подсосали" старый вариант Квери, то это будет сложно (невозможно?) проверить обычным сравнением (что вы будете при этом сравнивать в двух кверях? откуда вы знаете, что в сохранённой квере добавил пользователь, а что из класса жёстко прошито?)... Просто подтянется старая, вероятно уже неправильная, Кверя. И результаты работы класса будут просто непредсказуемыми....

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

Также следует учитывать тот факт, что typeOf() возвращает только базовые типы, а не типы из Extended Data Types.

Это значит, что если в списке переменных произошла замена одной переменной на другую с разным типом EDT, но основанным на одном и том же базовом типе, то также возможны проблемы. Будете делать проверку через sysDict...()?

В общем случае, проверка на typeOf() может служить дополнительным контролем, но он не заменяет проверки на номер версии.

[ZVV]

Цитата:

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

Также следует учитывать тот факт, что typeOf() возвращает только базовые типы, а не типы из Extended Data Types.

да, тоже обратил внимание на это... можно поменять 2 переменные местами в "листе" и всё равно будет всё "работать"

Цитата:

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

Это значит, что если в списке переменных произошла замена одной переменной на другую с разным типом EDT, но основанным на одном и том же базовом типе, то также возможны проблемы. Будете делать проверку через sysDict...()?

а вообще, разве можно это реализовать в данном случае? никогда не задумывался об этом, но разве в контейнере хранится расширенный тип исходного помещаемого значения? Мне кажется более вероятным, что только базовый тип хранится: строка и строка, число и число... Хотя я не утверждаю, Аксапты под ругой нет проверить...

[gl00mie]

Цитата:

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

разве в контейнере хранится расширенный тип исходного помещаемого значения? Мне кажется более вероятным, что только базовый тип хранится: строка и строка, число и число...

Как минимум, для строковых значений хранится длина строки, для enum'ов - тип enum'а. Это упоминалось в теме Axapta и BLOB поля, а более подробно было расписано на стороннем ресурсе, но он сейчас недоступен