Modified поля на форме-наследнике RunBase

[decoder]

Всем привет!
Отчет. Для задания его параметров делаю форму на базе RunBase. Кроме самого запроса на ней отображается 7 полей:
1. дата начала
2. дата конца
3. контрагент
4. ...
Никак не пойму почему модификация 3го по счету поля (контрагент) не отлавливается методом fld3_1_modified()? Зато отлавливается "динамически" либо через fld4_1_modified() либо fld5_1_modified().... Почему?

[kvg6]

Цитата:

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

Никак не пойму почему модификация 3го по счету поля (контрагент) не отлавливается методом fld3_1_modified()? Зато отлавливается "динамически" либо через fld4_1_modified() либо fld5_1_modified().... Почему?

Eсли включен showQueryValues(), порядковый номер поля на форме считается начиная с полей запроса

[DSPIC]

Цитата:

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

Всем привет!
Отчет. Для задания его параметров делаю форму на базе RunBase. Кроме самого запроса на ней отображается 7 полей:
1. дата начала
2. дата конца
3. контрагент
4. ...
Никак не пойму почему модификация 3го по счету поля (контрагент) не отлавливается методом fld3_1_modified()? Зато отлавливается "динамически" либо через fld4_1_modified() либо fld5_1_modified().... Почему?

Вот поэтому, в таких случаях, лучше не лениться и использовать форму вместо технических лазеек типа fld5_1_modified(). Через пару месяцев захотите(кто-то захочет) добавить 8-е поле где-нить в серединке, и все ивенты поедут к бабушке...
И суппортить такой оптимальный код невыносимо неприятно.

[Gustav]

Цитата:

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

Вот поэтому, в таких случаях, лучше не лениться и использовать форму вместо технических лазеек типа fld5_1_modified(). Через пару месяцев захотите(кто-то захочет) добавить 8-е поле где-нить в серединке, и все ивенты поедут к бабушке...

Можно перейти от fld5_1 к "нормальному" названию поля типа "Kontragent", создав переменную контрола соответствующего типа, и тогда метод приобретет более осмысленное название типа Kontragent_modified(). Соответственно, никаких проблем с последующим добавлением полей в серединку не возникнет. Делал такое в Ax 3.0 sp4. Примера кода под рукой сейчас нет - нахожусь в отпуске. Но как только доберусь до Аксапты (где-нибудь через недельку), то если вспомню - выложу. Там ничего особо сложного.

[gl00mie]

Коллега придумал оригинальный и вполне надежный способ гарантированно перехватывать события на полях диалога - даже когда заранее неизвестно, сколько полей будет в этом диалоге выведено (ну, в разумных пределах, конечно). Суть-то проблемы в чем?

1. Методы-перехватчики идентифицируются формой в соответствии с названиями контролов на форме;
2. Названия полям диалога даются в зависимости от числовых идентификаторов, присваиваемых объектам DialogField при добавлении полей в диалог, а также от индекса отображаемого DialogField'ом поля в поле-массиве (обычно этот индекс равен 1) - см. метод \Classes\DialogField\fieldname;
3. В диалог в зависимости от настроек может быть добавлено произвольное количество дополнительных полей - это происходит при вызове super() в перекрытом методе \Classes\RunBase\dialog, в результате управлять нумерацией объектов DialogField внутри диалога при добавлении их методами addField()/addFieldValue() становится затруднительно.

Так вот, чтобы принудительно задавать эти самые номера объектам DialogField, коллега нашел такой способ:

class   DEV_FormMethodOverloadSample
extends RunBase
{
    // ссылка на диалог понадобится для методов-обработчиков
    // событий на полях диалога, которые мы собираемся повесить
    Dialog      dialog;
    DialogField df1;
    DialogField df2;
    // задаем идентификаторы для DialogField, заведомо бОльшие
    // того количества полей, которое может быть добавлено в диалог
    #define.DlgFldNum1  (10240)
    #define.DlgFldNum2  (10241)
    // ...
}
protected Object dialog(DialogRunbase _dialog = null, boolean _forceOnClient = false)
{
    ;
    dialog = super( _dialog, _forceOnClient );
    // вот в чем фишка! создаем DialogField сами и "привязываем" к диалогу
    df1 = new DialogField( dialog, typeid(AmountCur), #DlgFldNum1 );
    df1.init( dialog );
    // значение df1 можно установить здесь же или в putToDialog()

    df2 = new DialogField( dialog, typeid(JournalId), #DlgFldNum2 );
    df2.init( dialog );
    // ...
    return dialog;
}
public void dialogPostRun(DialogRunbase _dialog)
{
    super( _dialog );
    // вешаем свои обработчики на некоторые события контролов диалоговой формы
    // NB! наш класс должен иметь свойство RunOn == Client или Called from
    // и canSwapBetweenCS() должен возвращать true, иначе этот код будет
    // вызван на сервере, и никакого _dialog.formRun() мы не увидим
    _dialog.formRun().controlMethodOverload( true );
    _dialog.formRun().controlMethodOverloadObject( this );
}
protected boolean fld10240_1_modified()         // df1
{
    FormRealControl formControl;
    boolean         ret;
    ;
    formControl = dialog.formRun().controlCallingMethod();
    ret = formControl.modified();               // вызываем super()
    if (ret)
    {
        // дальше выполняем нужные действия
    }
    return ret;
}
protected void fld10241_1_lookup()              // df2
{
    FormStringControl formControl;
    ;
    formControl = dialog.formRun().controlCallingMethod();
    // дальше выполняем нужные действия
}

[Logger]

Классно.

А была еще похожая тема
Как задать имя контрола на RunBase

[Logger]

Думаю надо бы все это в полезные материалы занести.

[Logger]

Еще
Перекрыть LookUp в RunBase

[kashperuk]

Ну, раз уж делимся ссылками, запостю и свою (мне это решение, ессно, нравится больше всего ), правда требует модификации системных классов диалога
Позволяет указать название для создаваемого DialogField, а соответственно называть метод именно FieldName_modified(), etc.
В проект включены еще две полезности

http://kashperuk.blogspot.com/2007/0...xtensions.html

[mazzy]

Цитата:

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

Думаю надо бы все это в полезные материалы занести.

Добавил тег "Полезное".
И вы тоже так можете.

[decoder]

Еще трабл
При модификации одного поля мой метод .._modified() меняет значение другого поля формы, но никак не пойму: как при этом обновить форму без перехода на следующее поле диалога..

[Gustav]

Цитата:

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

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

Если контрол, modified() которого должен срабатывать - не комбо-бокс, а к примеру обычное текстовое поле, то никак. Подумайте сами - чтобы сработал modified надо как-то объяснить системе, что редактирование закончено. Стандартно это происходит при переходе к другому контролу. Ну или надо пересчет другого поля добавлять не в modified, а в обработку какого-нибудь другого события, которое условиться считать сигналом окончания редактирования, например, mouseDblClick

[dech]

Цитата:

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

Еще трабл
При модификации одного поля мой метод .._modified() меняет значение другого поля формы, но никак не пойму: как при этом обновить форму без перехода на следующее поле диалога..

Как уже сказали, *_modified() работает только для лукап-полей. Для текстовый полей используйте метод *_textchange()

[propeller]

protected void fld10240_1_modified()            // df1
{
    FormRealControl formControl;
    ;
    formControl = dialog.formRun().controlCallingMethod();
    if (formControl.modified())                 // вызываем super()
    {
        // дальше выполняем нужные действия
    }
}

А в Ax 4.0 такое должно работать?
Сделал все так как в примере, только у меня класс наследник класса, который наследник от RunBase (не думаю что это как то влияет)

При изменении значения поля, только звук ошибки выдает винда. Причем нужно раза два еще щелкнуть на другое поле, чтобы соскочить с того поля, которое менял. В итоге значение поля остается тем же.
Проверил дебагером, в метод ld10240_1_modified
попадает причем два раза:
1 - из \Classes\FormComboBoxControl\SelectionChange
2 - из \Classes\FormComboBoxControl\leave

[gl00mie]

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

PS. Благодаря mazzy пример исправлен.

[Denicce]

Не получается перехватить метод performFormLookup, остальные нужные методы работают.
Это нужно, чтобы в уже готовой форме лукапа наложить фильтр. В нашем едт CustAccount используется своя форма выбора. Можно, конечно, в методе lookup использовать не SysTableLookup, а нашу форму, но раз уж речь зашла о переопределении методов элементов управления в диалоге, может, как-то возможно решить эту проблему?

// dfCustAccont.performFormLookup()
protected void fld10240_1_performFormLookup(FormRun _form)
{
    FormDatasource  fds = _form.dataSource();
    FormStringControl formControl;
    ;
    formControl = dialog.formRun().controlCallingMethod();
    fds.query().dataSourceTable(tablenum(CustTable)).addRange(fieldnum(CustTable, Name)).value("а*");
    formControl.performFormLookup(_form);              
}