Kashperuk Ivan: 3 Dialog extensions

[Blog bot]

Источник: http://kashperuk.blogspot.com/2007/0...xtensions.html
==============

Performing one of the modifications on the project I am currently working on, I had to modify the behavior of one of the basic classes using the RunBase framework.

Anyway, what I needed to do was:

1. Override the basic lookup for a specific control on the dialog.
2. Prevent user interaction with other forms until the dialog is closed.
3. Make some of the controls in the dialog mandatory.

Well, the perfect solution here would be to create a Form, and use it as the dialog.
But the code was very highly customized, so it would be a hard job.
So I decided to go another way, using what I have on hand, and that is the Dialog class.
For that, I needed a couple of modifications to the Dialog class, as it does not allow any of the 3 features I neded.

But what any developer should clearly understand when using dialogs is - this is just another form. Simple as that - Dialog is just another AOT form. What this means is that with a dialog we can do all the things we can do with a form.
Also, which is very nice and I thank DAX Developers for that, RunBase framework uses DialogRunBase class for showing forms, and this class is extending from class Dialog, so changes made to Dialog will also be available in RunBase framework.

Here is a small explanation of what has been modified:

• Added a class Dialog variable showModal, which controls the modal state of the used dialog. 
• Added a parm method to set the value of the showModal variable. So, basically, to make a modal dialog you simply have to call this method passing true as the parameter.
• Added a method SetFormModal, which actually does all the enabling/disabling of windows (DAX 3.0 only, as DAX 4.0 already has built-in modal forms)
• Modified runOnClient() method to allow server dialogs to run modal as well
• Modified wait() method, which calls SetFormModal method (DAX 3.0 only)
• AddField and AddFieldd modified to allow specifying a specific name for a control.
• DialogField class was modified to allow setting the mandatory property (mandatory(), unpack() methods) and specifying a specific name for a control (new and fieldname methods)

The project contains 4 objects:

• Class\Dialog - only modified methods
• Class\DialogField - only modified methods
• Class\Tutorial_RunBaseForm
• Jobs\tutorial_DialogModalMandatory

The tutorials show the features added to the Dialog and DialogField classes (one of them is present in the basic application and is extending from RunBase, using an AOT form, the second is a job, showing the use of Dialog class)

DAX 3.0 Download link (was created in DAX 3.0 SP5 KR2) - DOWNLOAD
DAX 4.0 Download link (was created in DAX 4.0 SP1 EE) - DOWNLOAD

Important:
After importing the project do not forget to compile forward the Dialog class and to restart the DAX client.

Certain Issues you should know about:

1. InfoActions, if present, will allow to access forms, if the infolog window with them was opened before the modal dialog was called.
2. Mandatory property starts working only after a value is entered into the control. What this means is that if you simply press OK right after the dialog is opened, you won't receive an error (regular forms works this way too)

Credits
The modification allowing to specify a specific name for a DialogField was originally posted on the Russian Axapta forum

Источник: http://kashperuk.blogspot.com/2007/0...xtensions.html

[Lazy_Tiger]

Цитата:

Сообщение от Blog bot

Certain Issues you should know about:

1. Mandatory property starts working only after a value is entered into the control. What this means is that if you simply press OK right after the dialog is opened, you won't receive an error (regular forms works this way too)

не удалось ли победить ?

[kashperuk]

Цитата:

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

не удалось ли победить ?

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

Думаю, чтобы грамотно это исправить - надо копаться в ядре.

Кстати, вчера вот как раз нужно было controlMethodOverload делать для диалога класса, который исполняется на сервере.

Так вот, в вышеприведенном job нету для этого механизма.
Если кому интересно будет, подготовлю и выложу здесь небольшое дополнение, чтобы работало .

[kashperuk]

Обновил проекты по вышеприведенным ссылкам.

Исправил глюк с работой функциональности указания конкретного имени контрола (если класс на сервере работает)
Добавил возможность использования метода dialogPostRun в случае, когда класс работает на сервере. (для того, чтобы достучаться до formRun диалога)

Юзайте на здоровье.

[ziva]

Цитата:

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

Юзайте на здоровье.

Ну или вот это: Перекрыть LookUp в RunBase.

Можно делать изюмительные вещи (см. пример во вложениях).