Как заставить работать xRecord.suppressWarnings()

[Logger]

Добрый день.

Кто нибудь смог заставить работать метод
xRecord.suppressWarnings()

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

Как заставить её замолкнуть не знаю.
Пробовал использовать suppressWarnings() - значение устанавливается, но никак не влияет.

[sukhanchik]

Есть более общая идея - в классе Info (системном) - объявляется некая переменная типа boolean: например - boolean locked
Затем делается parm-метод на этом классе - достукивающийся до этой переменной.
В широко известном методе add того же класса Info, в начале метода делается проверка - например:

PHP код:

if (locked)
       return 


Далее, пользуясь глобальной переменной infolog - можно в коде на некое время запретить выводить в инфолог сообщения:

PHP код:

infolog.parmLocked(true);
.....
infolog.parmLocked(false); 


[Logger]

Интересный способ.
Но так радикально я не собирался решать проблему...

Видимо придется.

[DenisS]

А у кого-либо есть идея как глобально (для всех таблиц) перекрыть метод validateField или validateWrite.
Это нужно для того, чтобы в поле, являющимся первичным ключом справочника запретить ввод спец.символов: ? * , ! и т.д.

[AndyD]

Насчет возможности перекрытия validateField или validateWrite ничего сказать не могу, но думаю, что это невозможно.

А проверять первичный индекс на валидность можно непосредственно на сервере б/д в триггерах before insert. В принципе и для Oracle и для MS SQL можно написать скрипт, который будет бежать по метаданным и генерить скрипты для добавления соответствующих триггеров, так что по трудоемкости это будет не безумная задача

[DenisS]

2 AndyD
Такой подход ясен. При этом можно не заморачиваться с триггерами на Sql - сервере, можно написать джобик, который пройдется по AOT и сделает нужные изменения прямо в методах таблиц Axapta, но это усложнит переход на новые версии.
Я до конца не докопал, но возможно есть способ перекрывать методы не xRecord, а FormDataSource, поскольку такая проверка нужна только при ручном вводе данных.
Решения пока не нашел.
2 All: Есть идеи?

[itfs]

Отладчики туде не ходят, ни у таблиц, ну у датасорсов .... думаю дело почти дохлое.

С уважением, itfs.

[DenisS]

Отладчики туда не ходят, но они ходят в Classes\SysSetupFormRun, где можно вытащить FormDataSource - но дальше - тупик.

[itfs]

Ну почему тупик ... дальше можно вызвонить таблицу по AOT и динамечески перекрыть ей методы .... было бы чем .... получим самораспространяющуюся функциональность.

С уважением, itfs.

[DenisS]

2 itfs: Это Круто, такого подхода я еще не встречал. Интересно как это работающая система будет программировать самою себя...

[itfs]

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

С уважением, itfs.

[AndyD]

2 DenisS

Когда я писал об использовании триггеров, я в первую очередь имел в виду минимизацию изменения кода приложения. Кроме того, как вы собираетесь изменять уже существующие методы на таблицах? Или у вас есть парсер?

2 itfs

Чем изменение кода во время выполнения приложения лучше контролируемого изменения до?

[belugin]

Цитата:

2 AndyD Такой подход ясен. При этом можно не заморачиваться с триггерами на Sql - сервере, можно написать джобик, который пройдется по AOT и сделает нужные изменения прямо в методах таблиц Axapta, но это усложнит переход на новые версии. Я до конца не докопал, но возможно есть способ перекрывать методы не xRecord, а FormDataSource, поскольку такая проверка нужна только при ручном вводе данных. Решения пока не нашел.

У меня вот какие мысли:

1. можно попробовать сделать то же самое на уровне форм
(класс SysFormRun, но это в качестве идеи - я сам пока не вижу подробно реализацию)

2. Если аккуратно сделать Job, то также аккуратно можно и убрать результаты его работы другим джобом - это не должно усложнить переход на новые версии.

[itfs]

Цитата:

Изначально опубликовано AndyD
2 itfs

Чем изменение кода во время выполнения приложения лучше контролируемого изменения до? [/B]

Да хуже, хуже. Но я бы немного не так позиционировал свое предложение. Я предлагал изменять код не везде (это очень и очень много, а кроме того, со временем все больше и больше). А ровно там, где это будет затребовано конкретной эксплуатацией. Надеюсь было понятно, что генерация состоится только 1 раз во время первого запуска кем - либо.

С уваженим, itfs.

PS. Естественно, самораспространяющийся код должен быть безупречен, иначе, есть риск войти в историю создателем 1-го вируса на Аксапте, причем на свою же голову.