Модификация DialogField

[Eldar9x]

На классе наследованном от RunBase построен диалог на котором динамически создаются несколько контролов. Нужно при модификации одного из контролов делать еще какие-нибудь вещи. Вариант с dialogObj.allowUpdateOnSelectCtrl(true);
this.dialogSelectCtrl(); подходит, но работает немного коряво, то есть приходится для активации/деактивации контрола вначале перейти на него.
Слышал про еще один способ, в котором используется значение dlgfJournalNameId.Name(), в результате которого получаем строку dlg1_.... Потом на классе создается метод, не уверен в названии - dlg1_Modified потом ядро само выовет этот метод при изменении контрола. Может кто слышал?

[kashperuk]

Посмотри вот здесь
http://kashperuk.blogspot.com/2007/0...xtensions.html

Там улучшения + примеры - в примерах делается требуемая тебе логика (правда там _lookup, а не _modified, но суть та же)

[Eugene Murka]

Цитата:

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

Потом на классе создается метод, не уверен в названии - dlg1_Modified потом ядро само выовет этот метод при изменении контрола. Может кто слышал?

Да,всё верно,создаёте метод dlg1_Modified,где dlg1 - имя контрола, при изменении значения контрола вызовется этот метод.Так вы можете прописать любые методы стандартного контрола.

[konopello]

2 Eldar9x, Eugene Murka, kashperuk Я в таких случаях больше предпочитаю вместо динамического дилога вызывать форму.

см. \Classes\Tutorial_RunbaseForm

public Object dialog()
{
    dialogRunbase   dialog = dialog::newFormnameRunbase(formstr(tutorial_RunbaseForm),this);
;
    dialog = super(dialog);

    dlgTransDate = dialog.addField(typeid(transDate));
    dlgtransDate.value(transDate);

    return dialog;
}

[petr]

Цитата:

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

Я в таких случаях больше предпочитаю вместо динамического дилога вызывать форму.

Слава богу, разработчики аксапты тоже пока предпочитают вызывать статическую форму из АОТа в таких случаях.

Надеюсь, и в дальнейшем так будет.

[Eugene Murka]

Цитата:

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

Слава богу, разработчики аксапты тоже пока предпочитают вызывать статическую форму из АОТа в таких случаях.

Надеюсь, и в дальнейшем так будет.

Особенно это будет полезно,если от диалога нужно будет создать наследников!
Взяли вы форму наваяли там кучу контролов и функционала,а потом нужно её чуть-чуть изменить и использовать в другом месте...копируете вместе со всем кодом,что является грубым нарушением принципов ООП.

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

И самое главное,форма и все её методы будут выполнятся на клиенте,а это может быть неприемлемо,когда всё остальное работает на сервере.

[zZ_TOP_Zz]

А все таки, не могли бы вы более подробно описать код для этих методов. Очень интересная штуковина.

[Eugene Murka]

Цитата:

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

А все таки, не могли бы вы более подробно описать код для этих методов. Очень интересная штуковина.

А что описывать - создаёте наследника от Runbase, методе dialog() прописываете контрол,скажем myControlTxt, создаёте новый метод,называете его myControlTxt_Modified запускаете диалог и при изменении значений в myControlTxt будет срабатывать myControlTxt_Modified, всё аналогично статической форме.

[kashperuk]

Цитата:

Сообщение от Eugene Murka

А что описывать - создаёте наследника от Runbase, методе dialog() прописываете контрол,скажем myControlTxt, создаёте новый метод,называете его myControlTxt_Modified запускаете диалог и при изменении значений в myControlTxt будет срабатывать myControlTxt_Modified, всё аналогично статической форме.

Ну, раз уж такое дело, то дело совсем не в этом.
Главным моментом является вызов 2 методов класса FormRun

controlMethodOverload(true)
controlMethodOverloadObject(this)

Это значит, что класс (this) будет управлять методами формы.

Такой подход используется, к примеру, при работе панелей (listpanels), как на форме Users/User Groups, т.д

[zZ_TOP_Zz]

Цитата:

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

Ну, раз уж такое дело, то дело совсем не в этом.
Главным моментом является вызов 2 методов класса FormRun

controlMethodOverload(true)
controlMethodOverloadObject(this)

Это значит, что класс (this) будет управлять методами формы.

Такой подход используется, к примеру, при работе панелей (listpanels), как на форме Users/User Groups, т.д

Да именно так и сделал
в классе создал метод

boolean controlMethodOverload()
{
   return true;
}

получил значение контрола, изменения которого надо отслеживать, создал метод
fld4_1_modified(), где fld4_1 именно значение контрола (формируется Аксой) в нем описал обработку и все заработало.

Вроде как все.

[konopello]

Цитата:

Особенно это будет полезно,если от диалога нужно будет создать наследников!
Взяли вы форму наваяли там кучу контролов и функционала,а потом нужно её чуть-чуть изменить и использовать в другом месте...копируете вместе со всем кодом,что является грубым нарушением принципов ООП.

полностью не согласен, посмотрите как организованы диалоги для классов SalesFormLetter и PurchFormLetter и их наследников.

Цитата:

И самое главное,форма и все её методы будут выполнятся на клиенте,а это может быть проблемой.

так что получается, по вашему форма должна выполнятся на сервере ..........(ужас)

[Eugene Murka]

Цитата:

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

полностью не согласен, посмотрите как организованы диалоги для классов SalesFormLetter и PurchFormLetter и их наследников.

так что получается, по вашему форма должна выполнятся на сервере ..........(ужас)

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

И если вы не в курсе,некоторые объекты выполняются на сервере,а некоторые на клиенте,формы - это интерфейс,выполняется на клиенте всегда,а вот классы можно вызывать где угодно.

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

[Eldar9x]

Всем большое спасибо, особенно, Kashperuk . Хотелось бы добавить только, что вариант с вызовом готовой формы, более трудоемок, так как эту форму сначало надо сделать...

[petr]

Цитата:

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

Всем большое спасибо, особенно, Kashperuk . Хотелось бы добавить только, что вариант с вызовом готовой формы, более трудоемок, так как эту форму сначало надо сделать...

Ну раз он для вас более трудоемок, то, конечно, пожалуйста, ваше право.

Я в свое время (в начале работы с Аксаптой) тоже был поклонник такого подхода. По-моему, даже на форум писал. Только вот прошло время, пришел опыт. Сейчас страшно вспоминать, что я иногда в Аксапте писал, включая и динамические формы в диалоге. Ужас!

[konopello]

класс SalesFormLetter всегда работает на сервере а диалог на клиенте.

salesEditLines = classFactory.formRunClass(FormLetter::newClientArgs(formStr(SalesEditLines), this));

ключевая фраза FormLetter::newClientArgs.

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

[konopello]

Цитата:

Всем большое спасибо, особенно, Kashperuk . Хотелось бы добавить только, что вариант с вызовом готовой формы, более трудоемок, так как эту форму сначало надо сделать...

отчасти согласен, когда логика формы довольно простая.

[Eldar9x]

Цитата:

когда логика формы довольно простая.

а когда сложная - тем более ))