Динамическое добавление контролов на форму

[erudit]

Привет эксперты!

Есть вопрос на засыпку.

У меня задача динамически создавать и добавлять контролы на форму в зависимости от текущей записи на родительской форме (т.е. вызывать обновление в linkActve() дочерней формы)

Родительская форма содержит инф-ю о том какие контролы должны быть добавлены на дочернюю форму (их имена и т.п.), т.е. заранее добавить контролы и прятать/показывать - не подходит.

В дочерней форме уже добавлен dataSource и все динамические контролы должны связываться с ним и показывать значение полей текущей записи (которая связана с таблицей в родительской форме и также обновляется по linkActive() ).

Теперь вопрос знатокам:
Исходя из вышеописанного сценария, контролы добавляются уже после вызова init() в дочерней форме и соотв. formBuildControl-классы наследники уже использовать нельзя, а только обычные formControl-классы.

При это возникается проблема - контролы теряют размер EDT, не показывают данные записи и т.п.

Как это решить?
Может я что-то упускаю?

Буду очень БЛАГОДА за любые идеи!

[mazzy]

Цитата:

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

У меня задача динамически создавать и добавлять контролы на форму в зависимости от текущей записи на родительской форме (т.е. вызывать обновление в linkActve() дочерней формы)

1. не мучайте птичку.
2. вместо того, чтобы "создавать" лучше "удаляйте" контролы. создайте одну большую форму на все случаи жизни и просто скрывайте ненужные контролы. И будет вам щастье. Именно в таком подходе заключается "дао Аксапты".
3. (унылым голосом Иа-Иа) если же не хотите слушать, а хотите непременно "проложить свою колею", то посмотрите в форму tutorial_Form_AddControl

[DSPIC]

1. Добавил в форму \Forms\tutorial_Form_AddControl датасорс InventTable
2. Модифицировал метод \Forms\tutorial_Form_AddControl\Designs\Design\[ButtonGroup:ButtonGroup]\Button:Button\Methods\clicked:

void clicked()
{
    FormBuildDesign             formBuilddesign = form.design();
    FormBuildGroupControl       formBuildGroupControl;
    FormStringControl c;
    ;
    c = addGroup.addControl(FormControlType::String,'RunTimeControl');
    c.label("New control");

    // DSPIC -->
    c.dataSource(InventTable_ds.id());
    c.dataField(fieldnum(InventTable, ItemId));
    c.displayLengthValue(10);
    InventTable_ds.executeQuery();
    // DSPIC <--

    formBuildGroupControl = formBuildDesign.control( addGroup.id() );
}

Данные отображаются, корректно. Длина от EDT действительно не подтягивается, нужно поиграться , посмотреть. Но сходу видно, что c.displayLengthValue(10); оказывает влияние, и накрайняк этим можно воспользоваться.

См. также \Classes\SysTableBrowser

[oip]

Цитата:

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

1. Добавил в форму \Forms\tutorial_Form_AddControl датасорс InventTable
2. Модифицировал метод \Forms\tutorial_Form_AddControl\Designs\Design\[ButtonGroup:ButtonGroup]\Button:Button\Methods\clicked:

Если кто на моем проекте попытается такое без действительно осо-о-о-обой необходимости (пока на моей практике такой не было) сделать, я ему руки оборву.

+1 к словам mazzy и sukhanchik. Контролы надо не добавлять, а скрывать.

[sukhanchik]

Аксапта - такая система, в которой скажем так... разработчики ядра (ax32.exe) не соревнуются в плане качества поставляемых API (системных классов, таблиц и т.д.), т.е. какие-то вещи, которые с т.з. разработчика должны работать - могут не работать или иметь какие-то глюки. Это, кстати - говоря - не про Микрософт будет сказано - а про тех, кто это писал до Микрософта.
Поэтому - какие-то (иногда кажущиеся очевидными) идеи технически нереализуемы и поэтому приходится менять постановку задачи.

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

Конструктивно, по вопросу - "на лету" добавлять контрольки (т.е. не formBuild*-классами) - нельзя. Ну точнее - есть проблемы с привязкой к данным и т.д. В 3.0, я, поковырявшись с этим, похоронил эту идею. В 4.0 - может что-то и изменилось - но не думаю.

В примере, указанном DSPIC контрол действительно добавляется... Но боюсь, что на linkActive такое может не сработать. Просто потому что linkActive. А SysTableBrowser не показатель - т.к. там контролы добавляются до вызова run(), т.е. через FormBuild*, а не через Form*-классы

[DSPIC]

Цитата:

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

Аксапта - такая система, в которой скажем так... разработчики ядра (ax32.exe) не соревнуются в плане качества поставляемых API (системных классов, таблиц и т.д.), т.е. какие-то вещи, которые с т.з. разработчика должны работать - могут не работать или иметь какие-то глюки. Это, кстати - говоря - не про Микрософт будет сказано - а про тех, кто это писал до Микрософта.
Поэтому - какие-то (иногда кажущиеся очевидными) идеи технически нереализуемы и поэтому приходится менять постановку задачи.

нифига не понял, это вы о чем?

Цитата:

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

В Вашем случае - лучшим решением будет отказаться от решения Вашей задачи таким способом.

Я бы вначале попросил описать задачу подробнее, прежде чем давать советы по реализации.

Цитата:

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

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

Посмотреть как это сделано в другом месте можно в \Forms\tutorial_Form_AddControl

Цитата:

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

Конструктивно, по вопросу - "на лету" добавлять контрольки (т.е. не formBuild*-классами) - нельзя. Ну точнее - есть проблемы с привязкой к данным и т.д. В 3.0, я, поковырявшись с этим, похоронил эту идею. В 4.0 - может что-то и изменилось - но не думаю.

Конструктива не увидел:
- Контролы добавлять можно, проблем с данными нет - я это показал
- "поковырявшись с этим, похоронил эту идею" - возможно, вам не хватило навыков, ковыряясь в 3.0 ? В чем именно была проблема ?

Цитата:

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

В примере, указанном DSPIC контрол действительно добавляется... Но боюсь, что на linkActive такое может не сработать. Просто потому что linkActive. А SysTableBrowser не показатель - т.к. там контролы добавляются до вызова run(), т.е. через FormBuild*, а не через Form*-классы

Смею вас заверить, что на linkActive такое сработает. Обоснуйте свои опасения.

Цитата:

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

Просто потому что linkActive

потому что гладиолус (С)

[mazzy]

Цитата:

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

- "поковырявшись с этим, похоронил эту идею" - возможно, вам не хватило навыков, ковыряясь в 3.0 ? В чем именно была проблема ?

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

[DSPIC]

Цитата:

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

Наезд
...

Да, высказывания sukhanchik'а в очередной раз не аргументированы, более того, противоречивые. Тем не менее, извините.

Цитата:

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

Если кто на моем проекте попытается такое без действительно осо-о-о-обой необходимости (пока на моей практике такой не было) сделать, я ему руки оборву.

+1 к словам mazzy и sukhanchik. Контролы надо не добавлять, а скрывать.

Согласен, я бы тоже оборвал. Но, я исходил из условия:

Цитата:

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

...
Родительская форма содержит инф-ю о том какие контролы должны быть добавлены на дочернюю форму (их имена и т.п.), т.е. заранее добавить контролы и прятать/показывать - не подходит.
...

В общем, развернутое ТЗ в студию, после чего можно продолжить по существу.

[miklenew]

Есть задачи, которые по другому кроме как динамическим добавлением контролов не реализуются.
В Ax-e пока с таким не сталкивался. Но если будут, твёрдо утверждать что задача плохая и нужно пересматреть её реализацию или отказаться не буду.
Пример.
Давно была такая задача. Реализовывал на C++ Builder.
Есть таблица в неё забиваються операции и время работы этих операций.
Эти операции должны были появиться на сэнсорном экране в два столбца в виде кнопок с названиями этих операций. Форма на весь экран.
На протяжении дня кнопки могли перераспределяться в зависимости от того сколько времени и обрабатываеться ли это операция в это время.
Пришлось делать.
Подобные задачи думаю и в аксе могут быть.
Кликнул оператор склада одну из волшебных кнопок и наступило счастье, кликнул кнопку которая рядом счастье отсторнировалось.
Если есть у человека время и желание зачем отговаривать.
Я думаю что он уже понял, что нужно ещё раз подумать, а только потом приступать.

[sukhanchik]

За день моего отсутствия со стороны DSPIC столько возражений - что прям уж даже удивительно почему у него ко мне такое неравнодушие

Цитата:

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

нифига не понял, это вы о чем?

Я думаю, что те люди, которые сталкиваются с программированием в Аксапте, придя из других систем - понимают о чем я писал. У Вас никогда не бывало такого, что Вы ожидаете от метода некий результат - а по факту он не соответствует Вашим ожиданиям?
Чтобы не быть голословным - скажу, что на таблице есть методы validateField и validateWrite. Методы похожи по своему названию и предназначению. Но validateField только информирует пользователя о том что не прошла проверка, но при этом записывая в поле неверное значение, а validateWrite не дает обновить (добавить) запись, если проверка не прошла. Возможно - этот нюанс описан в документации (=> это не бага, а фича). Но для программиста, начинающего осваивать систему (коим скорее всего является автор ветки) - это как раз тот случай, когда ожидания не соответствуют реалиям.

Цитата:

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

Я бы вначале попросил описать задачу подробнее, прежде чем давать советы по реализации.

Конкретная задача описана достаточно подробно, чтобы сказать - что ТАК в Аксапте делать не нужно (хотя и технически возможно). А автор ветки может и не знать глобально всю задачу и уж тем более ему может затруднительно повлиять на изменение архитектуры решения задачи.

Цитата:

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

Посмотреть как это сделано в другом месте можно в \Forms\tutorial_Form_AddControl

Да, но Вы также отсылали к SysTableBrowser, что в условиях поставленной задачи (не использовать FormBuild*-классы) - совершенно бесполезный пример. Вы уж сами давайте четкие ответы - а то с одной стороны - для Вас задача описана недостаточно подробно, чтобы давать советы по реализации - а с другой стороны Вы их даете.

Цитата:

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

Конструктива не увидел:
- Контролы добавлять можно, проблем с данными нет - я это показал
- "поковырявшись с этим, похоронил эту идею" - возможно, вам не хватило навыков, ковыряясь в 3.0 ? В чем именно была проблема ?

Ну... я ж не претендую на идеальные знания во всех областях. Возможно, что в тот момент мне и не хватило навыков или условия были чуть-чуть другие (уже не помню).
Контролы добавлять технически можно. Это как с оповещениями в 4-ке - работают? Да. Маркетинг рекламирует. А то, что эта система ляжет, если повесить оповещения на InventTrans при относительно спокойной одновременной работе 15 пользователей с заказами - об этом нигде не говорится.
Так и тут. Пример есть. Просто можно пойти своим путем, насобирав кучу граблей и глюков, а можно пойти проверенным путем (FormBuild*) и прийти к тому же результату - только без грабель. Т.е. что-то где-то не отобразится, что-то где-то не подтянется, EDT может некорректно подхватиться, форма будет тормозить с перерисовыванием и т.д. Я не знаю всего. В свое время я делал форму, в которой настройками в таблице задавалось - какие контролы нужно отображать. Помню - что в конечном счете я пришел к варианту показа скрытых контролов - иначе то ли чего-то вылетало толи еще чего-то. Но и то - форма тормозила и определенные визуальные "прыжки" иногда наблюдались. Вывод - так делать неправильно. Хотя и технически возможно.

Цитата:

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

Смею вас заверить, что на linkActive такое сработает. Обоснуйте свои опасения.

Опасения связаны с тем, что событие срабатывает при каждом изменении позиции курсора. Добавлять контролы (а не показывать скрытые) на этом событии - может привести к вылету Аксапты. Уточню: это мои опасения (т.е. как Вы говорите - голословные утверждения). Может такого и не случится. Можете считать меня в этом случае параноиком или менее компетентным, чем Вы в этой области.

Со своей стороны попрошу Вас, DSPIC - обосновать Ваше утверждение ссылками "Да, высказывания sukhanchik'а в очередной раз не аргументированы". А то иначе получается откровенный наезд (я бы даже это счел за оскорбление).

[DSPIC]

Цитата:

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

...
Со своей стороны попрошу Вас, DSPIC - обосновать Ваше утверждение ссылками "Да, высказывания sukhanchik'а в очередной раз не аргументированы". А то иначе получается откровенный наезд (я бы даже это счел за оскорбление).

Извините, наверное, с кем-то Вас перепутал.

[erudit]

Всем отвещавшим огромное спасибо! Получил много полезной инф-ии для размышления.

После всего вышеуслышенного, постараюсь пойти немного другим путём и всё таки следуя "дао Аксапты" создавать контролы до init() используя FormBuild-классы, а в методе active() родительской формы, проверять открыта ли дочерняя форма и если да, то закрывать и открывать её заново. Есть сомнения насчёт UI - мерцаний и т.п., но т.к. лучшего варианта похоже нет, то пользователю придётся смириться.

Ещё раз большое спасибо за скорую помощь!

[DSPIC]

Цитата:

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

... а в методе active() родительской формы, проверять открыта ли дочерняя форма и если да, то закрывать и открывать её заново...
Ещё раз большое спасибо за скорую помощь!

Не за что, всегда рады помочь!

[igorian]

вопрос, а реализуемо ли такое добавление контролов на web форме ?

webForm.addControl - будет работать?

[morza]

а как из класса динамически добавить контрл?