Переопределение стандартных методов у динамически создаваемых контролов - вопрос с предисторией (многабукаф)

[TasmanianDevil]

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

Этот мой класс получает родительский контрол на форме и создает на нем динамическую группу контролов и является дополнительным обработчиком событий контролов для формы. У динамически создаваемых контролов мы можем переопределять их методы путем написания на обработчике (им может быть сама форма или некий отдельный класс) соответствующих методов, чьи имена являются композициями имени контрола и имени переопределяемого метода. Все хорошо и замечательно, lookup'ы перехватываются и отрабатываются. Для EDT-массива из 8 уровней пришлось переопределять 8 lookup'ов.

Собственно вот эти 8 методов и не дают покоя ввиду личного перфекционизма - lookup'ы обрабатываются одним и тем же отдельным обработчиком, вызовы которого в переопределенных методах (да и сами методы) на классе-движке отрисовки отличаются только индексом внутри массива - все остальное идентично, т.е. по сути эти 8 штук методов легко заменяемы на один метод с параметром. Собственно отсюда и растут ноги вопроса - можно ли как-то, не имея переопределенных по вышеупомянутым правилам методов на обработчике, тем не менее отловить на родительской форме срабатывание события (конкретно, вызова lookup) от динамически созданного контрола и идентифицировать контрол (а через него и до индекса в EDT-массиве рукой подать), породивший это событие ?

Форма внутри у себя в любом случае получает запрос на обработку события на контроле ...

[S.Kuskov]

Цитата:

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

Форма внутри у себя в любом случае получает запрос на обработку события на контроле ...

Это наверное только на уровне оконной процедуры можно поймать. Т.е. хук нужен. ИМХО овчинка выделки не стоит.

А нельзя все восемь контролов связать с одним обработчиком и уже оттуда попытаться идентифицировать контрол? Например, через метод formRun.selectedControl()

[mazzy]

Цитата:

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

можно ли как-то, не имея переопределенных по вышеупомянутым правилам методов на обработчике, тем не менее отловить на родительской форме срабатывание события (конкретно, вызова lookup) от динамически созданного контрола и идентифицировать контрол (а через него и до индекса в EDT-массиве рукой подать), породивший это событие ?

Форма внутри у себя в любом случае получает запрос на обработку события на контроле ...

можно
Как можно перекрыть метод контрола формы, создаваемого в runtime?
Многоуровневый справочник

и далее поиск по форуму по ключевому слову controlMethodOverloadObject

[gl00mie]

Цитата:

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

можно ли как-то, не имея переопределенных по вышеупомянутым правилам методов на обработчике, тем не менее отловить на родительской форме срабатывание события (конкретно, вызова lookup) от динамически созданного контрола и идентифицировать контрол (а через него и до индекса в EDT-массиве рукой подать), породивший это событие ?

А что если в EDT прописать FormHelp и уже во вспомогательную форму lookup'а вынести нужную логику? Она в любом случае получает контрол, по контролу можно получить ссылку на DataSource и идентификатор поля (у вас же bound-контрол?), а дальше - выполнять нужную логику, как вариант, на вызывающей форме можно сделать метод, который будет возвращать ссылку на движок, собственно содержащий нужную логику, и форма lookup'а может дергать этот движок...

[AndyD]

Цитата:

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

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

Этот мой класс получает родительский контрол на форме и создает на нем динамическую группу контролов и является дополнительным обработчиком событий контролов для формы. У динамически создаваемых контролов мы можем переопределять их методы путем написания на обработчике (им может быть сама форма или некий отдельный класс) соответствующих методов, чьи имена являются композициями имени контрола и имени переопределяемого метода. Все хорошо и замечательно, lookup'ы перехватываются и отрабатываются. Для EDT-массива из 8 уровней пришлось переопределять 8 lookup'ов.

Собственно вот эти 8 методов и не дают покоя ввиду личного перфекционизма - lookup'ы обрабатываются одним и тем же отдельным обработчиком, вызовы которого в переопределенных методах (да и сами методы) на классе-движке отрисовки отличаются только индексом внутри массива - все остальное идентично, т.е. по сути эти 8 штук методов легко заменяемы на один метод с параметром. Собственно отсюда и растут ноги вопроса - можно ли как-то, не имея переопределенных по вышеупомянутым правилам методов на обработчике, тем не менее отловить на родительской форме срабатывание события (конкретно, вызова lookup) от динамически созданного контрола и идентифицировать контрол (а через него и до индекса в EDT-массиве рукой подать), породивший это событие ?

Форма внутри у себя в любом случае получает запрос на обработку события на контроле ...

Если я правильно понял суть вопроса - что-то подобное реализовано в адресном движке в DAX2009 (по-моему, начиная с RU7) - класс FormRunListener_Address_RU
Там реализованы единые методы-обработчики событий для контролов адресов. Определение вызывающего контрола - через вызов controlCallingMethod()

[TasmanianDevil]

Цитата:

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

можно

либо я жостко туплю и не вижу очевидного, либо вопрос был прочитан по диагонали ... Еще раз опишу ситуацию:

• Есть на форме динамически созданные контролы (флаг LookupButton) - 8 штук
• Есть на форме класс, зарегистрированный как доп. обработчик событий контролов формы
• Есть 8 методов по переопределению lookup() этих контролов на классе обработчике - все восемь штук абсолютно идентичны, за исключением одного параметра, а именно индекса в массиве EDT

В моем вопросе предметом является возможность замены N методов из последнего пункта на один (т.е. эти 8 удалить, а оставить один)

[TasmanianDevil]

Данная задача усугубляется парой особенностей технологической реализации

• EDT-массив унаследован от RefRecId
• Выводимые и обрабатываемые контролы - display/edit-методы по полю на таблице с этим EDT
• Правила lookup и отображение display/edit - методах зависитот поля с EDT-массивом типов ссылок, определяемым в каждой конкретной записи таблицы ссылкой на статью, в справочнике которых для каждой определено, на каком уровне должна быть ссылка на какой справочник

Т.е. вариации игрищ с EDT и FormHelp'ами отпадают ...

[S.Kuskov]

Цитата:

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

Данная задача усугубляется парой особенностей технологической реализации
...
Т.е. вариации игрищ с EDT и FormHelp'ами отпадают ...

Не понял как всё вышеперечисленное ограничивает вас в использовании единого EDT и FormHelp в качестве шлюза для вход в ваш мегасуперпупер навороченный алгоритм определения нужного лукапа. Туда же можно перетащить весь контекст вызова и таблицу и текущую строку и всё что захотите ...

P.S.: А совет AndyD про formRun.controlCallingMethod() прочитали?

[TasmanianDevil]

Цитата:

Сообщение от S.Kuskov

Не понял как всё вышеперечисленное ограничивает вас в использовании единого EDT и FormHelp

FormHelp общий для EDT, а у меня разные уровни ссылаются на разные таблицы и один и тот же уровень в разных записях может ссылать на разные таблицы - все определяется отдельным полем-массивом, определяющим таблицы ссылки по уровням.

[S.Kuskov]

Да пусть ссылаются куда нужно. Использование единого значения в свойстве FormHelp не обязывает вас этот же FormHelp использовать в качестве формы для лукапа. Идея же была в том чтобы при помощи FormHelp перехватить упраление созданием лукапа. А отображать можно для каждого поля свой лукап. Это же всё программируется...

И ещё раз. AndyD подсказал, как мне кажется, более красивый способ решения вашей задачи.

[TasmanianDevil]

S.Kuskov, а смысл - лукап инициализируется из контрола, которое привязано не к самому полю с EDT, а к контролу с edit/display методом и с данного контрола получить информацию о EDT поля-источника не получится.
Вариант AndyD изучаю, только вот мозг сломал в самом главном моменте - как и за счет чего лукапы с нескольких разноименных контролов попадают в один метод FormRunListener_Address_RU !?
Мозг просто взрывается

[AndyD]

Цитата:

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

Вариант AndyD изучаю, только вот мозг сломал в самом главном моменте - как и за счет чего лукапы с нескольких разноименных контролов попадают в один метод FormRunListener_Address_RU !?

Они все создаются с одним именем address_control.

[S.Kuskov]

Цитата:

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

S.Kuskov, а смысл - лукап инициализируется из контрола, которое привязано не к самому полю с EDT, а к контролу с edit/display методом и с данного контрола получить информацию о EDT поля-источника не получится.

Из ваших рассуждений в первом сообщении я понял, что для решения задачи достаточно будет "идентифицировать контрол". Выходит это не так?

[TasmanianDevil]

Цитата:

Сообщение от S.Kuskov

Из ваших рассуждений в первом сообщении я понял, что для решения задачи достаточно будет "идентифицировать контрол". Выходит это не так?

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

AndyD реально аццкое колдунство раскрыл - про возможность создания BuildControl'ов с одинаковыми именами в runtime не подозревал За что ему поклон нижайший ...