Хм.. Вроде как и есть что сказать по теме, но, вроде бы и так уже все сказано. Только систематизировано несколько по другому, из-за чего и "едет крыша". Как мне кажется, критически важным является ответ на первую "хотелку".
Цитата:
Сообщение от
mazzy
Какие манипуляции хотелось бы делать с подобными значениями в Аксапте:
Возможные варианты:
- Выделить (интерпретировать) одно из значений как null
- Выделенное значение отображается как пустое значение в диалоге с пользователем (255 для Base Enum, num2char(160) для String, 0.0001 для AmountCur, 0.1 для CheckBox и т.д и т.п.)
- Выделенное значение не может быть отображено "как есть" в диалоге с пользователем. Требуется "перевод" (maxDate() для Date, maxInt() для int и т.п.)
- Добавить еще один признак (поле), показывающий, что "основное" значение надо интерпретировать как null. Одно дополнительное поле может "обслуживать" несколько "основных" полей.
- Отдельный признак имеет самостоятельное значение и отдельно отображается в диалоге с пользователем. Например, признак "Контролировать кредитный лимит" определяет учитывать ли значения полей "Сумма лимита" и "Дата установки контроля"
- Отдельный признак является "системным" (служебным) полем и для пользователя недоступен. Например, признак значения NULL для контрольной суммы (Хотя... Впрочем, за не именеем более наглядного примера)
Дальнейшая реализация будет существенным образом зависеть от выбранного способа хранения значения NULL в базе данных. Ну, с первыми 3 вариантами дальнейшая работа понятна. Обычный набор переменных. Некоторые сложности может доставить перекодировка из maxdate() в пустое значение для отображения, но не думаю, что эта такая уж большая проблема.
Проблемным является последний вариант, когда дополнительный признак является служебным полем, недоступным для прямого просмотра/изменения пользователем. Вот здесь на первое место выступает вторая ключевая "хотелка"
Цитата:
Сообщение от
mazzy
- спрашивать значения у пользователя на формах и в программных диалогах
Каким образом будет построен интерфейс с пользователем, чтобы пользователь мог понять, где значение будет интерпретировано как null, а где - как указанное значение? Пусть даже пользователь и "не трогал" этого значения. Или "потрогал", но вернул назад
Вообще-то, мне приходит в голову только один вариант на подобный случай. Это когда речь идет о полях, которые пользователь изменить не может. Максимум посмотреть. Та же контрольная сумма. Но это значит, что речь идет о неких расчетных значениях, которые, очевидно, зависят от других реквизитов. Так может, можно эти самые "другие реквизиты" и использовать как признак значения NULL?
Если же рассматривать вопрос БЕЗ учета этих двух основных "хотелок", например, как передача неких параметров при расчетах, то можно рассмотреть еще парочку вариантов.
- Очень ограниченно можно использовать (prmIsDefault() == 1) как признак того, что параметр передан не был. Т.е. интерпретировать это как передачу null. Правда, для pack/unpack это не пригодно, но ведь интерфейс с пользователем нас не интересует
- В среде Axapta значение NULL физически может быть сохранено в переменной типа ComVariant. В принципе, тот же класс, но чуть проще
X++:
COMVariant comVariant;
;
comVariant = new ComVariant(COMVariantInOut::In_out, ComVariantType::VT_BOOL);
info(comVariant.toString());
info(strFmt('%1',comVariant.variantType()));
comVariant.variantType(ComVariantType::VT_NULL);
info(comVariant.toString());
info(strFmt('%1',comVariant.variantType()));