![]() |
#1 |
Мрачный тип
|
Переопределение стандартных методов у динамически создаваемых контролов - вопрос с предисторией (многабукаф)
Занимаюсь сейчас одной разработкой, а именно классом-движком отрисовки и обработки событий для табличного поля с EDT-массивом и имеющего сложные правила выбора значений в него. Поле это предполагается использовать в широком ряде таблиц и, соответственно, чего не хочется делать - так это программировать лукапы и корежить дизайны в куче форм, что собственно и послужило идеей создания такого класса.
Этот мой класс получает родительский контрол на форме и создает на нем динамическую группу контролов и является дополнительным обработчиком событий контролов для формы. У динамически создаваемых контролов мы можем переопределять их методы путем написания на обработчике (им может быть сама форма или некий отдельный класс) соответствующих методов, чьи имена являются композициями имени контрола и имени переопределяемого метода. Все хорошо и замечательно, lookup'ы перехватываются и отрабатываются. Для EDT-массива из 8 уровней пришлось переопределять 8 lookup'ов. Собственно вот эти 8 методов и не дают покоя ввиду личного перфекционизма - lookup'ы обрабатываются одним и тем же отдельным обработчиком, вызовы которого в переопределенных методах (да и сами методы) на классе-движке отрисовки отличаются только индексом внутри массива - все остальное идентично, т.е. по сути эти 8 штук методов легко заменяемы на один метод с параметром. Собственно отсюда и растут ноги вопроса - можно ли как-то, не имея переопределенных по вышеупомянутым правилам методов на обработчике, тем не менее отловить на родительской форме срабатывание события (конкретно, вызова lookup) от динамически созданного контрола и идентифицировать контрол (а через него и до индекса в EDT-массиве рукой подать), породивший это событие ? Форма внутри у себя в любом случае получает запрос на обработку события на контроле ...
__________________
Мы летаем, кружимся, нагоняем ужасы ... |
|
![]() |
#2 |
Участник
|
Цитата:
А нельзя все восемь контролов связать с одним обработчиком и уже оттуда попытаться идентифицировать контрол? Например, через метод formRun.selectedControl() |
|
![]() |
#3 |
Участник
|
Цитата:
Сообщение от TasmanianDevil
![]() можно ли как-то, не имея переопределенных по вышеупомянутым правилам методов на обработчике, тем не менее отловить на родительской форме срабатывание события (конкретно, вызова lookup) от динамически созданного контрола и идентифицировать контрол (а через него и до индекса в EDT-массиве рукой подать), породивший это событие ?
Форма внутри у себя в любом случае получает запрос на обработку события на контроле ... Как можно перекрыть метод контрола формы, создаваемого в runtime? Многоуровневый справочник и далее поиск по форуму по ключевому слову controlMethodOverloadObject |
|
![]() |
#4 |
Участник
|
Цитата:
Сообщение от TasmanianDevil
![]() можно ли как-то, не имея переопределенных по вышеупомянутым правилам методов на обработчике, тем не менее отловить на родительской форме срабатывание события (конкретно, вызова lookup) от динамически созданного контрола и идентифицировать контрол (а через него и до индекса в EDT-массиве рукой подать), породивший это событие ?
|
|
|
За это сообщение автора поблагодарили: S.Kuskov (1). |
![]() |
#5 |
Участник
|
Цитата:
Сообщение от TasmanianDevil
![]() Занимаюсь сейчас одной разработкой, а именно классом-движком отрисовки и обработки событий для табличного поля с EDT-массивом и имеющего сложные правила выбора значений в него. Поле это предполагается использовать в широком ряде таблиц и, соответственно, чего не хочется делать - так это программировать лукапы и корежить дизайны в куче форм, что собственно и послужило идеей создания такого класса.
Этот мой класс получает родительский контрол на форме и создает на нем динамическую группу контролов и является дополнительным обработчиком событий контролов для формы. У динамически создаваемых контролов мы можем переопределять их методы путем написания на обработчике (им может быть сама форма или некий отдельный класс) соответствующих методов, чьи имена являются композициями имени контрола и имени переопределяемого метода. Все хорошо и замечательно, lookup'ы перехватываются и отрабатываются. Для EDT-массива из 8 уровней пришлось переопределять 8 lookup'ов. Собственно вот эти 8 методов и не дают покоя ввиду личного перфекционизма - lookup'ы обрабатываются одним и тем же отдельным обработчиком, вызовы которого в переопределенных методах (да и сами методы) на классе-движке отрисовки отличаются только индексом внутри массива - все остальное идентично, т.е. по сути эти 8 штук методов легко заменяемы на один метод с параметром. Собственно отсюда и растут ноги вопроса - можно ли как-то, не имея переопределенных по вышеупомянутым правилам методов на обработчике, тем не менее отловить на родительской форме срабатывание события (конкретно, вызова lookup) от динамически созданного контрола и идентифицировать контрол (а через него и до индекса в EDT-массиве рукой подать), породивший это событие ? Форма внутри у себя в любом случае получает запрос на обработку события на контроле ... Там реализованы единые методы-обработчики событий для контролов адресов. Определение вызывающего контрола - через вызов controlCallingMethod()
__________________
Axapta v.3.0 sp5 kr2 |
|
|
За это сообщение автора поблагодарили: TasmanianDevil (3). |
![]() |
#6 |
Мрачный тип
|
либо я жостко туплю и не вижу очевидного, либо вопрос был прочитан по диагонали ... Еще раз опишу ситуацию:
__________________
Мы летаем, кружимся, нагоняем ужасы ... Последний раз редактировалось TasmanianDevil; 01.08.2012 в 12:55. |
|
|
За это сообщение автора поблагодарили: mazzy (2). |
![]() |
#7 |
Мрачный тип
|
Данная задача усугубляется парой особенностей технологической реализации
__________________
Мы летаем, кружимся, нагоняем ужасы ... |
|
![]() |
#8 |
Участник
|
Цитата:
P.S.: А совет AndyD про formRun.controlCallingMethod() прочитали? Последний раз редактировалось S.Kuskov; 01.08.2012 в 13:10. |
|
![]() |
#9 |
Мрачный тип
|
FormHelp общий для EDT, а у меня разные уровни ссылаются на разные таблицы и один и тот же уровень в разных записях может ссылать на разные таблицы - все определяется отдельным полем-массивом, определяющим таблицы ссылки по уровням.
__________________
Мы летаем, кружимся, нагоняем ужасы ... |
|
![]() |
#10 |
Участник
|
Да пусть ссылаются куда нужно. Использование единого значения в свойстве FormHelp не обязывает вас этот же FormHelp использовать в качестве формы для лукапа. Идея же была в том чтобы при помощи FormHelp перехватить упраление созданием лукапа. А отображать можно для каждого поля свой лукап. Это же всё программируется...
И ещё раз. AndyD подсказал, как мне кажется, более красивый способ решения вашей задачи. |
|
![]() |
#11 |
Мрачный тип
|
S.Kuskov, а смысл - лукап инициализируется из контрола, которое привязано не к самому полю с EDT, а к контролу с edit/display методом и с данного контрола получить информацию о EDT поля-источника не получится.
Вариант AndyD изучаю, только вот мозг сломал в самом главном моменте - как и за счет чего лукапы с нескольких разноименных контролов попадают в один метод FormRunListener_Address_RU !? Мозг просто взрывается
__________________
Мы летаем, кружимся, нагоняем ужасы ... |
|
![]() |
#12 |
Участник
|
Они все создаются с одним именем address_control.
__________________
Axapta v.3.0 sp5 kr2 |
|
|
За это сообщение автора поблагодарили: mazzy (2), gl00mie (2). |
![]() |
#13 |
Участник
|
Из ваших рассуждений в первом сообщении я понял, что для решения задачи достаточно будет "идентифицировать контрол". Выходит это не так?
|
|
![]() |
#14 |
Мрачный тип
|
Цитата:
AndyD реально аццкое колдунство раскрыл - про возможность создания BuildControl'ов с одинаковыми именами в runtime не подозревал ![]()
__________________
Мы летаем, кружимся, нагоняем ужасы ... |
|