EDT массив и одинаковые метки

[Eldar9x]

Добрый вечер.

Просто интересное наблюдение. Был нужен EDT строковый массив, у некоторых элементов которого метки бы повторялись (при разных HelpText). Вроде бы, волне нормальное желание. Но как оказалось, аксапта не позволяет добавить Array-элемент с меткой, которая присвоена уже другому элементу.
Однако это легко обходится изменением меток Array-элементов этого EDT в блокноте и загрузкой XPO-файла обратно.



AX2009

[gl00mie]

Цитата:

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

Был нужен EDT строковый массив, у некоторых элементов которого метки бы повторялись (при разных HelpText). Вроде бы, волне нормальное желание.

С точки зрения пользователя ничего нормального в этом, по-моему, нет. Прям как у логопеда из старого фильма "По семейным обстоятельствам": "...да нет же, я выфу на Ки'гэвской, а он - на Ки'гэвской"

[Eldar9x]

Цитата:

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

С точки зрения пользователя ничего нормального в этом, по-моему, нет. Прям как у логопеда из старого фильма "По семейным обстоятельствам": "...да нет же, я выфу на Ки'гэвской, а он - на Ки'гэвской"

Ну, почему же? Простой пример. Скажем, в таблице есть несколько полей типа EmplId. Мы хотим для каждого из них добавить поле Телефон. Для каждого EmplId поля есть на форме отдельная выделенная группа, в заголовке которой (группы) указывается что это за EmplId. Зачем именовать каждое поле Phone[i] различной меткой, если то, к чему она относится указывается в заголовке группы? Можно, конечно, это и сделать, но во-первых, мы получим слишком длинные и избыточные метки у полей на форме, а во-вторых, это подробное описание поля уже есть в HeplText.

[RVS]

Цитата:

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

в таблице есть несколько полей типа EmplId. Мы хотим для каждого из них добавить поле Телефон

Ага.. а потом туда же - адрес, ИНН...

Ни о чем не напоминает?

[gl00mie]

Цитата:

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

Скажем, в таблице есть несколько полей типа EmplId. Мы хотим для каждого из них добавить поле Телефон. Для каждого EmplId поля есть на форме отдельная выделенная группа, в заголовке которой (группы) указывается что это за EmplId.

Получается, что таблица (как элемент модели данных) подстраивается под форму (как элемент представления), и вне контекста данного конкретного представления с таблицей работать будет неудобно. Завтра сделают другую форму типа "номера для обзвона", с другими группами или без EmplId - и там будет куча полей с одинаковыми метками.
-Нюра, а мне брать данные для обзвона из поля "телефон" или же "телефон"?
-А вот и не угадала, Ира, бери из поля "телефон"!
Еще на грид такие поля классно вытаскивать...

Цитата:

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

подробное описание поля уже есть в HeplText.

Ну да, только чтобы его увидеть, надо шлепнуться курсором в поле и потом скосить взгляд на статусную строку, где показывается HelpText. Не угадал - шлепайся в следующее поле; очень удобно...
Впрочем, это все, конечно, - занудное брюзжание, однако датчане-основатели, на мой взгляд, не просто так ввели ограничение для меток полей-массивов К слову, решить "проблему" можно было и иначе: на EDT сделать нормальные различающиеся метки для каждого элемента массива, а потом поставить метку на поле таблицы - в этом случае тоже у всех элементов поля-массива метки окажутся одинаковыми.

[Eldar9x]

Цитата:

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

дисплей методом можно телефон вывести

Тоже кстати вариант, спасибо. Хотя плодить дисплей методы, наверное, тоже нехорошо. Потом к ним еще кэширование на форме делать...

Цитата:

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

К слову, решить "проблему" можно было и иначе

Не совсем... Если к примеру нам нужно две пары повторяющихся меток, то такой вариант не покатит.

Цитата:

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

А что будет в случае работы с фильтрами ? По метке конкретное поле будет неоднозначно определяться, что может приводить к неприятным багам.

и тут снова нам поможет HelpText

ps: так чего, кучу одинаковых полей плодить на таблице что-ли? Я понимаю минусы решения, но альтернатива-то какая?

[Zimes]

Мне кажется, практика создания уймы полей типа EmplId, особенно, если им соответствуют ещё какие-то поля. Самое правильное в такой ситуации - создать отдельную табличку, связанную с исходной хоть по рекИд. И там уже плодить все эти пары. Если нужно их как-то различять для целей фильрации - добавить поле спецификатор.

А на худой конец сделать пару полей типа финансовой аналитики.

[ice]

дисплей методом можно телефон вывести

[Logger]

Цитата:

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

Был нужен EDT строковый массив, у некоторых элементов которого метки бы повторялись (при разных HelpText). Вроде бы, волне нормальное желание. Но как оказалось, аксапта не позволяет добавить Array-элемент с меткой, которая присвоена уже другому элементу.

А что будет в случае работы с фильтрами ? По метке конкретное поле будет неоднозначно определяться, что может приводить к неприятным багам.

[gl00mie]

Цитата:

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

Цитата:

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

А что будет в случае работы с фильтрами ? По метке конкретное поле будет неоднозначно определяться, что может приводить к неприятным багам.

и тут снова нам поможет HelpText

Имелось в виду то, что форма расширенного фильтра при указании метки поля может подхватить не то поле для фильтрации, которое пользователь предполагал, глядя на HelpText

Цитата:

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

Я понимаю минусы решения, но альтернатива-то какая?

Например, перебивание меток на лету на данной конкретной форме, раз особенности ее дизайна предполагают одинаковые метки у кучи полей. В callback-методе можно анализировать свойства dataField()/dataSource() (последнее должно быть равно FormDS.id() для нужной таблицы) и менять метки на то, что нужно. Надо только учесть, что у контролов dataField() - всегда расширенный идентификатор поля, и его для удобства надо обрабатывать с помощью fieldExt2Id().