Перехвать событий поля диалога в репорте

[zipo]

Существует ли возможность перехватить событие (modified например) для поля диалога на репорте созданом с помощью фреймворка где нету класса, а методы (dialog, pack, unpack) идут на саммом репорте?

Т.е. я понимаю, что нужно использовать методы
dlg.formRun().controlMethodOverload( true );
dlg.formRun().controlMethodOverloadObject( this );

Но их нужно вызвать на dialogPostRun диалога, а как в репорте добраться до него не вижу.

[kornix]

Если правильно понял, вы пытаетесь сделать это?

[zipo]

Цитата:

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

Если правильно понял, вы пытаетесь сделать это?

нет. Мне нужно проинициализировать перехват событий диалоговых полей в случае репотра который сидит на фреймвоке RunbaseReportStd

Т.е. я не знаю куда втулить
dlg.formRun().controlMethodOverload( true );
dlg.formRun().controlMethodOverloadObject( this );

что бы заработал перехват.

[Волчара]

Цитата:

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

нет. Мне нужно проинициализировать перехват событий диалоговых полей в случае репотра который сидит на фреймвоке RunbaseReportStd

Т.е. я не знаю куда втулить
dlg.formRun().controlMethodOverload( true );
dlg.formRun().controlMethodOverloadObject( this );

что бы заработал перехват.

Стандарты работы с классом Dialog не подразумеваю перехват событий. Так что надо модифицировать класс....

[mazzy]

Цитата:

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

Мне нужно проинициализировать перехват событий диалоговых полей в случае репотра который сидит на фреймвоке RunbaseReportStd

Т.е. я не знаю куда втулить
dlg.formRun().controlMethodOverload( true );
dlg.formRun().controlMethodOverloadObject( this );

что бы заработал перехват.

Нарисуйте в АОТ специальную форму диалога.
нормальными средствами нормального АОТ создайте в в этой форме методы.
подключите вашу форму в RunbaseReportStd.

не занимайтесь динамическим программированием. юзайте статическое.

[mazzy]

Цитата:

Сообщение от Волчара

Стандарты работы с классом Dialog не подразумеваю перехват событий. Так что надо модифицировать класс....

+ Не подразумевают
- Ни в коем случае не модифицируйте класс. Сделайте нормальную форму и подключите ее к диалогу класса. Все необходимые методы для этого есть. примеры смотрите в аксапте (например, создание заказа)

[Raven Melancholic]

Но в примерах на SYS слое есть и обратные примеры, например класс BOMChangeItem.
PS: на самом деле, я сам всегда делаю отдельную форму, если нужна обработка событий.

[zipo]

Цитата:

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

Нарисуйте в АОТ специальную форму диалога.
нормальными средствами нормального АОТ создайте в в этой форме методы.
подключите вашу форму в RunbaseReportStd.

не занимайтесь динамическим программированием. юзайте статическое.

Это у меня репорт с возможностью батча, батчевый фреймворк уж точно не предполагает нормальных способов через АОТ (зачем мне нужно рисовать еще форму под батч возможности и иметь "трудности" с подключением батчевого функционала). А диалог при наличии оверлоадинга имхо таки предполагает подключение к стандартным собитиям. Я этим не раз уже пользовался при создании батчевых джоб, там это делает элементарно.
Вопрос в том, как это сделать на батчевом репорте со стандартным фрейворком RunbaseReportStd

[zipo]

Кто столкнется с такой же проблемой, то сделал такой солюшен:

В класс RunBaseReportStd добавляем такой метод

public void dialogPostRun(DialogRunbase dialog)
{
    ;
    super(dialog);
    reportRun._dialogPostRun(dialog);
}

В класс SysReportRun добавляем такой метод

public void _dialogPostRun(DialogRunbase dialog)
{
    ;
    if (this.reportHasMethod(methodstr(RunbaseReportStd, dialogPostRun)))
    {
        this.thisObject().dialogPostRun(dialog);
    }
}

Хоть это и изменение стандартных классов, ни к чему страшному это не приведет. Это просто добавление того функицонала который почему-то забыли сделать в стандартном RunBaseReportStd фрейм ворке, что бы включить функцию оверлоадинга

Дальше идет по обычной схеме, хотя она немного изменена:
Добавляем следующий метод в наш репорт:

public Object dialogPostRun(DialogRunbase _dialog)
{
    ;
    _dialog.formRun().controlMethodOverload(true);
    _dialog.formRun().controlMethodOverloadObject(dialogEvents);

    return _dialog;
}

dialogEvents - это экземпляр класса, который я инициализирую в репорте на init методе. Почему так каряво? Потому как обычный this или element не работает, скорее всего на оверлоадинг умеет проверять наличие метода только у класса. Поэтому нужен именно класс.

В классе dialogEvents у меня есть метод

boolean DateRange_modified()
{
    ;
    info("111");
    return true;
}

Где DateRange имя моего поля, метод прекрасно срабатывает на изменение этого поля, поэтому можно все обработать, т.к. легко сделать этому классу доступ к репорту.
Солюшен может показаться с подвыпердоворотом, но он надежен и исполняет свою функцию.