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

[gl00mie]

Для изменения свойств контролов на форме есть два подхода: либо править свойства в дизайне формы, либо делать это откуда-то из кода. Первый способ вроде бы наиболее простой, но он, порой, связан со значительными трудозатратами, кроме того, таким образом нельзя править свойства контролов, входящих в группы со свойством AutoDataGroup == Yes. При этом отказываться от этого чудесного свойства тоже не хотелось бы, поскольку оно позволяет за счет простого изменения группы полей на таблице менять перечень и порядок полей в группах на всех связанных формах.
С другой стороны, чтобы менять свойства контролов из кода, нужно обращаться к ним по одному, при этом контролы обычно должны иметь свойство AutoDeclaration == Yes, а для этого у группы, в которую входят контролы, необходимо обязательно выставить AutoDataGroup == No. Как вариант, можно в коде реализовать цикл обхода всех дочерних контролов той же группы, смотреть, к какому типу относится тот или иной дочерний контрол (потому что у наследников FormControl ряд свойств отличается, а в самом FormControl кое-какие свойства просто не реализованы, поэтому необходмо приведение типов дочерних контролов), тогда для группы можно оставить свойство AutoDataGroup == Yes. Но каждый раз организовывать такой цикл очень нудно: на одной и той же форме контролы в разных группах может понадобиться обрабатывать совершенно по-разному. Например, есть группы, в которые выведены коды пользователей либо сотрудников, а также display-методы для отображения их имен из таблицы сотрудников (EmplTable), плюс дата и время создания/модификации записи. Вот как это "штатно" выглядит:

Видно, что для кодов пользователей и сотрудников (userId/emplId) значения свойств displayLength у расширенных типов отличаются, а для имен и значений времени тут совершенно излишни метки. Хотелось бы, чтобы эти группы выглядели примерно так:

Так вот (та-да!) теперь этого можно легко добиться за счет использования итератора и методов обратного вызова, которые собственно будут устанавливать свойства контролов. В коде на форме это выглядит примерно так:

Set         setOfIds;
;
setOfIds = DEV_FormHelpers::addStringCtrlId2Set();    // на контролах какого типа должен дергаться метод обратного вызова
DEV_iterateThroughFormControls( GrpAuthorNames,         null, staticmethodstr(DEV_FormHelpers, hideLabel),      setOfIds, true, classnum(DEV_FormHelpers) );
DEV_iterateThroughFormControls( GrpAuthorIds,           null, staticmethodstr(DEV_FormHelpers, setColumnWidth), setOfIds, true, classnum(DEV_FormHelpers) );
setOfIds = DEV_FormHelpers::addTimeCtrlId2Set();
DEV_iterateThroughFormControls( GrpCreatedModifiedTime, null, staticmethodstr(DEV_FormHelpers, hideLabel),      setOfIds, true, classnum(DEV_FormHelpers) );

Здесь DEV_iterateThroughFormControls() - собственно метод-итератор, GrpAuthorNames и GrpAuthorIds - соотв. группы контролов со свойством AutoDeclaration == Yes, а DEV_FormHelpers - вспомогательный класс, чьи статические методы используются для выполнения действий над контролами. В принципе, ничто не мешает передавать в метод-итератор вместо null указатель на экземпляр какого-либо класса и название экземплярного метода этого класса, вместо того чтобы использовать статические методы DEV_FormHelpers.
Может возникнуть резонный вопрос, почему все-таки не изменить дизайн формы вручную раз и навсегда. Что ж, мне лично зачастую приходится создавать схожие по внешнему виду формы, отличающиеся некоторыми параметрами поведения и обрабатываемыми данными. Разумеется, лепить кучу форм-клонов неохота - куда интересней сделать одну форму и семейсво классов, управляющих ее поведением. Так вот, для изменения внешнего вида формы в зависимости от класса, который ей управляет, и понадобился такой механизм.
Метод-итератор для рекурсивного перебора контролов на форме использует интерфейс DEV_IFormContainerControl, представляющий общие методы контролов-контейнеров (FormButtonGroupControl, FormGridControl, FormGroupControl, FormMenuButtonControl, FormTabControl, FormTabPageControl и - с одной оговоркой - FormDesign). Также в проект включены и другие вспомогательные интерфейсы - DEV_IFormButtonControl (общие методы и свойства FormButtonControl, FormCommandButtonControl и FormFunctionButtonControl) и DEV_IFormGridContainedControl (общие методы и свойства контролов, которые могут появиться на гриде при использовании табличных групп полей). Единственное неудобство использования этих интерфейсов - это необходимость при присваивании "интерфейсным" переменным ссылок на наследники FormControl использовать промежуточное приведение к Object. Впрочем, избавление от необходимости приведения того же FormControl к нужному типу его наследника, чтобы дернуть какой-нибудь метод, не определенный на FormControl, и унификация работы со схожими типами контролов, на мой взгляд, с лихвой компенсирует это неудобство.

PS. Все это проверялось на AX3

[petr]

Zitat:

Zitat von gl00mie

С другой стороны, чтобы менять свойства контролов из кода, нужно обращаться к ним по одному, при этом контролы обычно должны иметь свойство AutoDeclaration == Yes, а для этого у группы, в которую входят контролы, необходимо обязательно выставить AutoDataGroup == No.

Непонял, что означает "обычно должны".

Вообще-то не должны. Для того, чтобы обатиться к контролу, у которого св-во AutoDeclaration установлено в No (например он входит в группу, и его св-ва недоступны) есть 2 способа.

1-ый. Работатет не для всех св-в, но не может породить run-time ошибки
FormDataSource.object(fieldId).visible(), enabled(), и некоторые другие.

2-ый. Предоставляет доступ ко всем св-вам, но может породить ошибку run-time
formStringControl = element.control(control::"имя контрола на форме");

[gl00mie]

Zitat:

Zitat von petr

Для того, чтобы обатиться к контролу, у которого св-во AutoDeclaration установлено в No (например он входит в группу, и его св-ва недоступны) есть 2 способа.
1-ый. Работатет не для всех св-в, но не может породить run-time ошибки
FormDataSource.object(fieldId).visible(), enabled(), и некоторые другие.

Не, тут на выходе получается не FormControl, а FormDataObject, что не одно и то же. Для того, что может FormDataObject, разумеется, никакие ковыряния в контролах не нужны и, более того, вредны с идеологической точки зрения. Если нужно управлять поведением поля datasource'а на форме, это и надо делать через datasource - тут кто бы спорил.

Zitat:

Zitat von petr

2-ый. Предоставляет доступ ко всем св-вам, но может породить ошибку run-time
formStringControl = element.control(control::"имя контрола на форме");

Именно этот способ я имел в виду, говоря «обычно должны иметь свойство AutoDeclaration == Yes». Но мне лично не нравится идея зашивать в код то, что нельзя проверить на этапе компиляции; на мой взгляд, использование enum'а Control на формах оправдано разве что в случае необходимости подправить дизайн формы через FormBuild-классы, т.е. до вызова super() в init() формы. Опять же, последний способ вынуждает обрабатывать контролы по одному, что мне лично не очень нравится.

[gl00mie]

В ряде случаев из-за кое-каких недотестированных доработок потребовалась возможность оперативно выяснять на формах, какие «на самом деле» суммы содержатся в отображаемых полях типа real. К примеру, забыли где-нить в импорте сумму округлять перед записью в поле таблицы, а потом - пойди, разберись, почему что-то не работает, ведь FormRealControl по умолчанию показывает значения с точностью лишь до двух знаков. Так вот, коллега на базе выложенного итератора реализовал возможность увидеть вещественные значения с большей точностью, приделав кнопку «Увеличить точность» к форме пользовательской настройки (SysSetupForm). На кнопке дергается такой код:

void clicked()
{
    super();
    infolog.startLengthyOperation();
    DEV_iterateThroughFormControls( sysSetupForm.getFormRun().design(),
                                    element,                        // объект, чей метод обратного вызова будет задействован
                                    @"DEV_setRealEditPrecision",    // название метода обратного вызова на форме SysSetupForm
                                    DEV_FormHelpers::addRealCtrlId2Set()
                                  );
    infolog.endLengthyOperation();
    element.close();                // показалось удобнее сразу закрывать форму настроек
}

В свою очередь, DEV_setRealEditPrecision() - это метод на форме SysSetupForm такого содержания:

// устанавливает для контролов RealEdit точность отображения минимум 6 знаков
#define.NewNoOfDecimals (6)
public void DEV_setRealEditPrecision(FormRealControl _formControl)
{
    if (!(  _formControl.noOfDecimalsMode() == AutoMode::Fixed
        &&  _formControl.noOfDecimalsValue() > #NewNoOfDecimals
       ))
    {
        _formControl.noOfDecimals( #NewNoOfDecimals, AutoMode::Fixed );
    }
}

Таким образом, за счет минимума кода стало можно на любой форме увидеть суммы/количества с большей точностью:

[Logger]

Zitat:

Zitat von gl00mie

...на мой взгляд, использование enum'а Control на формах оправдано разве что в случае необходимости подправить дизайн формы через FormBuild-классы, т.е. до вызова super() в init() формы...

с этого места поподробней пожалуйста...
т.е. возможны случаи когда мы работаем через енум Control, но не можем использовать AutoDeclaration ?

[gl00mie]

Дело в том, что свойство AutoDeclaration, насколько я могу судить, действует на FormXXControl'ы, но не на FormBuildXXControl'ы. Более того, если попытаться даже присвоить переменной типа FormBuildXXControl ссылку на элемент управления с AutoDeclaration == Yes, то такой код просто не скомпилируется по причине несовместимости типов. Соответственно, если требуется на форме до вызова super() в init() получить ссылку на какой-либо FormBuildXXControl, скажем, чтобы передать ее параметром в класс, то тут AutoDeclaration никак не поможет.
Вот пример из моего скромного опыта: есть «многофункциональная» форма, работающая на базе строк журналов. Многофункциональность заключается в том, что в зависимости от параметров вызова эта форма должна показывать немного различающиеся наборы полей и реализовывать немного различающуюся логику. Для этого ею рулит семейство классов, каждый из которых (наследник от базового) реализует эти незначительные отличия. И вот встает задача: в зависимости от параметров вызова, кроме прочего, показывать на гриде формы разные наборы полей, причем для простоты каждый набор задан группой полей на соотв. таблице. Варианты были такие:

• сделать на гриде кучу скрытых групп - по одной на нужную группу полей, а соответствующий класс будет делать видимой "свою" группу; но тут, выходит, надо ссылки на все эти группы передавать в класс, управляющий формой, либо реализовывать какую-то логику на форме (это хотелось делать в последнюю очередь, потому что исходно форма в плане логики "голая" - она только передает в класс ссылки на свои элементы и для некоторых событий дергает его обработчики);
• сделать на гриде одну группу полей и менять из класса ее свойство DataGroup после инициализации формы - этот вариант показал свою полную несостоятельность;
• сдалать на гриде одну группу полей и менять из класса ее свойство DataGroup до инициализации формы через ссылку на соотв. FormBuildGroupControl - на этом варианте я остановился.

Но тут встал вопрос: откуда добыть на форме ссылку на соотв. FormBuildGroupControl до инициализации формы, чтобы передать эту ссылку в класс? Я это сделал так:

element.form().design().control( Control::GrpGridFields );

тут, как видно, используется упомянутый enum Control, но AutoDeclaration задействовать в этом случае не представляется возможным.

[Wamr]

простите за вопрос.
На Dimension-полях работает?

[Logger]

Zitat:

Zitat von Wamr

простите за вопрос.
На Dimension-полях работает?

Мы проверяли - работает.

[sgt.Pepper]

Небольшое исправление к коду для 4.0:

DEV_FormHelpers

private static Set getSetOfClassIds(Set _set)
{
    classId     locClassId;
    Set         ret;
    ;
    if (_set)
    {
        if (_set.typeId() != typeof(locClassId))
        {
            //callStack2Infolog();
            // for 4.0
            info(con2str( xSession::xppCallStack() ));
            throw error( error::wrongUseOfFunction( funcname() ) );
        }
        ret = _set;
    }
    else
    {
        ret = new Set( typeof(locClassId) );
    }
    return ret;
}

[gl00mie]

Во вложении - вспомогательный класс для итератора, обновленный для использования в AX 2009.

PS. Для себя я сделал класс DEV_FormHelpers используемым в итераторе по умолчанию в тех случаях, когда в качестве метода обратного вызова указывается статический, а не экземплярный метод (т.е. _callbackObject == null):

public static client boolean DEV_iterateThroughFormControls(
    Object          _parentControl,
    Object          _callbackObject,
    identifiername  _callbackObjectMethodName,
    Set             _setOfClassIds2InvokeOn,
    boolean         _recursive                      = true,
    classId         _staticCallbackMethodClassId    = classnum(DEV_FormHelpers)
   )

[mazzy]

вопрос из другой ветки Как глобально отключить автоопределение ширины столбца = autoSizeColumns(false) ?

Zitat:

Zitat von gl00mie

Оно бы хорошо, если б речь шла об однократном привешивании картонки к фанерной стене, однако ж, если верить перекрестным ссылкам, я лично этот итератор уже использовал в 16-и различных местах приложения.

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

[gl00mie]

Zitat:

Zitat von mazzy

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

Собственно, большинство решаемых задач описаны в этой ветке:

• какие-то универсальные вещи, наподобие кнопки "увеличить точность отображения" в настройке форм (SysSetupForm) или уже обсуждавшаяся рихтовка свойств grid'ов различных форм;
• мелкая рихтовка вида контролов, которые входят в группы с AutoDataGroup = Yes (очень уж мне нравится это свойство, неохота от него отказываться из-за ерунды);
• более затейливые сценарии, когда, к примеру, "нужно сделать форму, доступную только на чтение", при том что у потенциального пользователя есть доступ к ключам контроля доступа с уровнем выше, чем чтение - в этом случае при запуске формы с определенным параметром помимо установки свойств datasource'ов еще можно пробежаться по всем кнопкам и те, у которых NeededAccessLevel больше View (т.е. действия которых могут изменять данные на форме), - скрыть. Можно возразить, что надо такие вещи решать настройками прав доступа, но, пардон, UAC в виндах решает примерно те же задачи: хочешь - работай под администратором, имея полные права на все, но по умолчанию в действиях будешь ограничен. Конечно, такой подход требует корректного выставления NeededAccessLevel на пунктах меню, но при "традиционной" настройке прав доступа это требование не менее актуально.
• сценарии, когда одна форма каких-нить журналов используется для ндцати (в моем случае - 10-и) немного отличающихся типов журналов, при этом одни и те же поля журналов для тех или иных типов могут иметь несколько отличающийся смысл, и пользователи хотят видеть там разные метки. В этом случае классы-наследники базового класса управления формой могут переопределить метод, возвращающий "нестандартную" метку для того или иного поля в строках журнала, а базовый класс дергает итератор, проходится по всем контролам, связанным с datasource'ом строк журнала, вызывает этот метод, возвращающий новую метку и, если возвращенное значение метки для поля, к которому привязан контрол, не пустое, устанавливает для контрола новую метку.

В общем, я лично с помощью итератора решаю в основном те задачи, которые при "традиционном" подходе требовали бы работы с каждым из заранее известного множества контролов в каждой из заранее известного множества форм, при том что эти множества на момент разработки могут быть еще неизвестны. "Традиционный" подход в таких случаях требует, как правило, слишком большого объема ручной работы, отказа от использования "автогрупп" контролов на основе табличных групп полей, внесения избыточных модификаций в стандартные формы (как с теми же гридами в AX 2009), плюс ко всему он еще и удорожает сопровождение сделанных модификаций.

[mazzy]

Zitat:

Zitat von gl00mie

[/LIST]В общем, я лично с помощью итератора решаю в основном те задачи, которые при "традиционном" подходе требовали бы работы с каждым из заранее известного множества контролов в каждой из заранее известного множества форм, при том что эти множества на момент разработки могут быть еще неизвестны. "Традиционный" подход в таких случаях требует, как правило, слишком большого объема ручной работы, отказа от использования "автогрупп" контролов на основе табличных групп полей, внесения избыточных модификаций в стандартные формы (как с теми же гридами в AX 2009), плюс ко всему он еще и удорожает сопровождение сделанных модификаций.

Но ведь при таком подходе SysSetupForm превращается в бутылочное горлышко, которое "знает" о деталях других форм. Т.е. в SysSetupForm будет некий большой switch, которые знает о деталях поведения других форм.

Это же противоречит объектно-ориентированному подходу и полностью нарушает инкапсюляцию.
Говоря в терминологии C++, ты создаешь класс, который является френдом очень многих других классов. Эдакий супер-френд. Со всеми вытекающими последствиями, которые вроде обсуждались у программистов С++. Например, чтобы выявить особенности поведения, тебе недостаточно понять как работает сам объект и его класс, тебе нужно понять как работают и все френды.

Разве не так?

[gl00mie]

Zitat:

Zitat von mazzy

Но ведь при таком подходе SysSetupForm превращается в бутылочное горлышко, которое "знает" о деталях других форм. Т.е. в SysSetupForm будет некий большой switch, которые знает о деталях поведения других форм.

А откуда взялось мнение, что всё вышеописанное реализуется в SysSetupForm? Там реализована только кнопка увеличения точности отображения, которая может быть применена к любой форме. Если же мне нужно переделать свойства пары контролов на форме, и я не хочу их для этого выдергивать из "автогруппы", то я просто дописываю метод на самой этой форме либо в классе управления этой формой, который при ее инициализации с помощью итератора меняет эти свойства. Пример такого метода приведен в самом первом сообщении данной темы (и в комментарии к нему ясно написано: "В коде на форме это выглядит примерно так").

PS. Сперва очень долго не мог понять, при чем тут вообще SysSetupForm - мне и в голову не могло прийти совать в него код, специфичный для особенностей дизайна какой-то одной конкретной формы.

[db]

Zitat:

Zitat von gl00mie

А откуда взялось мнение, что всё вышеописанное реализуется в SysSetupForm? Там реализована только кнопка увеличения точности отображения, которая может быть применена к любой форме. Если же мне нужно переделать свойства пары контролов на форме, и я не хочу их для этого выдергивать из "автогруппы", то я просто дописываю метод на самой этой форме либо в классе управления этой формой, который при ее инициализации с помощью итератора меняет эти свойства.

Для всяких хитровывернутых фич вещь, в принципе, полезная.

Но пара контролов на форме это пушкой по воробьям. Чем element.design().controlName() то не угодил? Вроде прекрасно достает контролы из автогрупп. Или уже не достает и я отстал от жизни?

[mazzy]

Zitat:

Zitat von gl00mie

А откуда взялось мнение, что всё вышеописанное реализуется в SysSetupForm?

А вот ни капельки такого мнения не было.
Реализуется метод в форме.
Но вызов то идет из SysSetupForm.
Это и есть friend.

Т.е. либо метод надо делать публичным, либо френдить SysSetupForm.
Поэтому SysSetupForm получается френдом для очень многих форм (другими словами, SysSetupForm слишком много знает о деталях реализации других форм), что приводит к снижению инкапсюляции.

(пусть в Аксапте нет ключевого слова friend. но смысл то и проблемы не меняются)

Zitat:

Если определяется класс, который не реализует математических объектов вроде матриц или комплексных чисел и не является типом низкого уровня наподобие связанного списка, то:
[а] Не используйте глобальных данных.
[b] Не используйте глобальных функций (не членов).
[c] Не используйте общих данных-членов.
[d] Не используйте функции friend (но только для того, чтобы избежать [а], [b] или [c]).
[e] Не обращайтесь к данным-членам другого объекта непосредственно.
[f] Не заводите в классе "поле типа"; используйте виртуальные функции.
[g] Используйте функции-подстановки только как средство значительной оптимизации.

...
Отметим, что общие базовые классы и друзья (friend) являются частью общего интерфейса класса (см. $$5.4.1 и $$12.4).

(C) Бьерн Страуструп. Язык программирования С++

[db]

Zitat:

Zitat von mazzy

А вот ни капельки такого мнения не было.
Реализуется метод в форме.
Но вызов то идет из SysSetupForm.
Это и есть friend.

Да нет там никаких таких вызовов (Функционал "расширения сознания" не в счет - он на своем месте). Все остальные специфичные для отдельных форм вещи реализуются прямо на этих отдельных формах

[gl00mie]

Понадобилось тут подпилить один кусок кода в стандартном приложении, в связи с чем в итератор и вспомогательный класс DEV_FormHelpers была добавлена поддержка FormBuild-контролов и опционального параметра, который может передаваться в вызываемый из итератора метод обратного вызова. Через этот параметр можно организовать общение метода с вызывающим итератор кодом без заведения глобальных переменных. Во вложении - обновленный метод Global (итератор), вспомогательный класс и вспомогательные интерфейсы, которые раньше были выложены отдельно.

PS. Теперь DEV_FormHelpers является классом по умолчанию, чьи статические методы обратного вызова используются, если не задана ссылка на объект, реализующий метод обратного вызова, соотв., не обязательно указывать идентификатор этого вспомогательного класса в вызове итератора.

[wojzeh]

работает эта штука и в AX 2012! только что применил к FormReferenceGroupControl

спасибо!