Как узнать контрол вызвавший дисплейный метод?

[Perc]

Ну собственно вопрос в теме)
Создал дисплей метод на датасорсе формы. Создал несколько полей на форме у которых datamethod - мой метод. Диспей метод прекрасно для всех срабатывает, но я хочу менять возвращаемое значение в зависимости от контрола. Вот как бы узнать какой контрол сработал?
ps. Делать разные дисплей методы не хочу. В итоге хочу динамические контролы)

[gl00mie]

Цитата:

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

я хочу менять возвращаемое значение в зависимости от контрола

Не страдайте ерундой

[Perc]

Цитата:

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

Не страдайте ерундой

Такой ответ я знаю и сам. Он не правильный)

[DSPIC]

Прямой ответ: технически нельзя.

Непрямой ответ:

Цитата:

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

Не страдайте ерундой

[Perc]

Цитата:

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

Прямой ответ: технически нельзя.

Ну получается тогда я не ерунду спросил) Про ерунду я и сам все знаю)

А вообще хотелось красиво и компактно заменить блок в форме выводящий наименование всех фин. аналитик. И заодно заложиться теоретически на изменение возможно их количества. Есть примеры накоряченные решения такой задачи. Но много текста или не универсально. Вот если бы у меня controlCallingMethod() сработал все бы вышло изящно. Два метода по пять строк)

[S.Kuskov]

Цитата:

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

Есть примеры накоряченные решения такой задачи.

Вы про это? Итератор с поддержкой методов обратного вызова для обработки контролов на форме

[Perc]

Цитата:

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

Вы про это? Итератор с поддержкой методов обратного вызова для обработки контролов на форме

Нет эту тему я не видел.
Но тут кстате забавно оказывается, что автор этой темы первый посоветовал не заниматься ерундой)

[ax_mct]

Цитата:

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

Ну получается тогда я не ерунду спросил) Про ерунду я и сам все знаю)

А вообще хотелось красиво и компактно заменить блок в форме выводящий наименование всех фин. аналитик. И заодно заложиться теоретически на изменение возможно их количества. Есть примеры накоряченные решения такой задачи. Но много текста или не универсально. Вот если бы у меня controlCallingMethod() сработал все бы вышло изящно. Два метода по пять строк)

Я прошу прощения и понимаю что вопрос чисто технический но все же.
Зачем? Даже если чисто для себя. Какое обоснование для данной модификации?
Будет ли это использоваться на живом приложении или это просто развлечение?

Что именно мешает использовать свой дисплейный метод для каждого контрола?
Не мое дело конечно, но просто в тему о "красоте" в "Прощай X++"

[S.Kuskov]

Цитата:

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

Зачем?

Цитата:

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

хотелось красиво и компактно заменить блок в форме выводящий наименование всех фин. аналитик. И заодно заложиться теоретически на изменение возможно их количества. )

.

[Perc]

Цитата:

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

Я прошу прощения и понимаю что вопрос чисто технический но все же.
Зачем? Даже если чисто для себя. Какое обоснование для данной модификации

Ну не просто технический, но и не жизненно необходимый. Вполне на рабочей форме хотел использовать. Совершенно обыкновенная весчь. Вытянуть наименования финаналитик рядом с кодами на стандарной закладке и как говориться забыть.

Цитата:

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

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

Хотелось выполнить не замысловатое условие - Не вспоминать про эту форму если мы вдруг меняем количество финаналитик в системе с 3 на 10, что есть довольно заурядная задача.
Шут с ним с дисплейным методом, предложите другой способ. У меня была реализация (писанная не мной), там метод актив на датасорсе дополнялся вытаскиванием наименований. Но мне он не понравился тем, что 10 запросов к справочнику аналитик шло даже если наименования на другом табе и его не смотрят.

[AraraT®]

Ловите стек вызовов

[Napalm]

Цитата:

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

Ну собственно вопрос в теме)
Диспей метод прекрасно для всех срабатывает, но я хочу менять возвращаемое значение в зависимости от контрола. Вот как бы узнать какой контрол сработал?

Легко - использовать для каждого контрола свой DataSource. А в display методе проверять какой DataSource его вызвал.

[Perc]

Цитата:

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

Легко - использовать для каждого контрола свой DataSource. А в display методе проверять какой DataSource его вызвал.

Какой то совершенно тяжелый и не универсальный геморой) О удобстве решения исходной задачи тут и речи нет... ну или не понял что имелось ввиду..

[Napalm]

Кстати есть и альтернативное решение - display метод возвращает все значения как массив, а каждый контрол показывает соответствующий ему элемент массива.

[ax_mct]

Цитата:

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

Кстати есть и альтернативное решение - display метод возвращает все значения как массив, а каждый контрол показывает соответствующий ему элемент массива.

Движок АХ, реализация кэширования вряд ли настолько крепки и неуязвимы против такого хакерства. И так стандартных проблем хватает а тут может валится еще и из-за таких нестандартных решений. Извращенная красота, злоупотребление гибкостью системы.
Даже если в данной сборке и прокатит то в любом случае уменьшает надежность системы. А она и так бедная кашляет и сопливиться. Ей такие сюрпризы не нужны

P.S. По идее система должна ругнуться на сложный тип в display методе. Но даже если у нее рот заткнут зачем ее насиловать? злодеи и колдуны. на костер

[Perc]

Цитата:

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

Кстати есть и альтернативное решение - display метод возвращает все значения как массив, а каждый контрол показывает соответствующий ему элемент массива.

Это тоже в разряд ерунды, не вижу плюсов у этого решения. Которое кстати надо еще заморочиться попрограммировать.

[ax_mct]

В принципе, можно проверять имя контрола и делать Switch по имени.
Возвращать естественно примитивный тип на базе string.
То есть можно сделать один дисплейный метод. Но это неправильно и неоправданно и недальновидно.
Еще немного и индусы с копи-пастом покажутся меньшим злом
Это НЕКРАСИВО на уровне дизайна. Для программиста (текущего или следующего) это только усложнение работы но не полезность. Попросту - извращение

[Perc]

Цитата:

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

В принципе, можно проверять имя контрола и делать Switch по имени.
Возвращать естественно примитивный тип на базе string.
То есть можно сделать один дисплейный метод. Но это неправильно и неоправданно и недальновидно.
Еще немного и индусы с копи-пастом покажутся меньшим злом
Это НЕКРАСИВО на уровне дизайна. Для программиста (текущего или следующего) это только усложнение работы но не полезность. Попросту - извращение

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

[S.Kuskov]

Цитата:

Сообщение от Владимир Максимов

Или что-то другое имеется в виду?

Наименование не аналитик, а значений аналитик

[ax_mct]

Цитата:

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

Наименование не аналитик, а значений аналитик

Только сейчас въехал в то что хочет автор. Так как при корректном добавлении финансовой аналитики, она прекрасно автоматически распадается на элементы массива на формах.

А вот когда значение аналитики "111" а пользователь хочет человеческое наименование справа то да, это задача частая и популярная.

Всегда ее решал на автомате и без проблем. Дополнительный контрол справа с дисплейным методом.

В принципе эти "Value's name" контролы можно добавлять автоматически при каждом запуске формы. Реализуемо, но я такое делать никогда не буду в силу бизнес-модели работы и нелепости самой задумки.

Интересно как часто добавляются финансовые аналитики Если часто то да можно сделать кнопку на форму - "Обновить контролы". Но это явно не так.

Если же как учебно-абстрактная задача то действительно достаточно азартно. Но я бы просто уточнил что хочет пользователь и изменил дизайн решения начиная с cамого начала. Например tooltips, mouseOver, hotkeys или просто показ комбинированного имени "ID (NAME)" вместо ID аналитики (в этом случае надо думать о длине или о новом EDT на форме что тоже неэлегантно).

Пойнт в том что если требуется сложное решение то значит надо менять дизайн.
Сложность решения на уровне кодирования это признак плохого дизайна или плохой идеи.

Самое простое это тупо ручками добавлять контрол для "Value's name". Не так часто это и случится. Но безусловно задача интересная, не могу этого не признать - просто я такие себе позволить просто не могу

В порядке бреда.
Вариант 1
EDT akaDimensionName. Добавить массив контролов "Value's name" на форму. Связь между контролами через одинаковый индекс в массивах.

Вариант 2
Показ грида [ID, NAME] с таблицей финансовой аналитики и фильтром по данному значению.

Вариант/Мысль? 3
Исходить из того у нас коллекция контролов в группе на форме и мы может их перебрать и что надо добавить.

Declaimer: это все несерьезно однако.