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

[Perc]

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

[gl00mie]

Цитата:

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

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

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

[Perc]

Цитата:

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

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

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

[DSPIC]

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

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

Цитата:

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

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

[AraraT®]

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

[Perc]

Цитата:

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

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

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

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

[S.Kuskov]

Цитата:

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

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

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

[ax_mct]

Цитата:

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

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

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

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

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

[Napalm]

Цитата:

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

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

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

[S.Kuskov]

Цитата:

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

Зачем?

Цитата:

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

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

.

[Napalm]

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

[ax_mct]

Цитата:

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

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

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

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

[ax_mct]

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

[Perc]

Цитата:

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

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

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

[Perc]

Цитата:

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

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

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

Цитата:

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

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

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

[Perc]

Цитата:

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

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

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

[Perc]

Цитата:

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

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

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

[Perc]

Цитата:

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

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

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

[Napalm]

Цитата:

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

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

И чем плох вариант с display методом возвращающим массив? При изменении к-ва аналитик с 3-10 не приходится модифицировать половину AX именно благодаря использованию массива для их хранения.

[Perc]

Цитата:

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

И чем плох вариант с display методом возвращающим массив? При изменении к-ва аналитик с 3-10 не приходится модифицировать половину AX именно благодаря использованию массива для их хранения.

Пробуем реализовать.
1. на что вешать дисплей метод? На все контролы? и все 10 будут делать десять запросов?
2. Ну предположим все таки както вернули массив. Как вы будете раздавать членов этого массива по клеточкам?)

ммм.. Не понимаю как не особо фанатея с кодом (дполнительные переменные хранения, проверки, контроль текущей записи..) решить задачу этим предположением.
И как в итоге решиться проблема роста аналитик и количества контролов на форме.. Утыкаемся туда же откуда начали.
В общем, лучше возьмите форму и попробуйте реализовать то о чем подумали) расскажите мне подробности) Задача то простейшая. И кода не должно быть больше чем 10 дисплейных методов)