Smarter dialogs
I don’t know about you, but it seems to me that dialogs for jobs in AX gets more and more complicated. I have a feeling a few of them could solve most of the world’s problems with hunger and pollution, if I could only figure out how fill the dialog fields correctly…
Users need help and guidance with the dialogs and to give the best guidance you may need to react to the choices made by the user in the dialog.
Two methods on RunBase allow you to hook up some events from the dialog form with your RunBase inheriting class:
- dialogSelectCtrl is executed every time a new control is selected. I.e. when you move from one field to another.
- dialogTask is executed every time the task method of the dialog form is called.
Here’s an example of how you can enable or disable fields based on what the users selects.
class dialogTest extends RunBase
{
DialogField dialogFieldCustVend;
DialogField dialogFieldCustAccount;
DialogField dialogFieldVendAccount;
}
public container pack()
{
return conNull();
}
public boolean unpack(container packedClass)
{
return true;
}
static void main(args _args)
{
dialogTest dialogTest = new dialogTest();
;
dialogTest.prompt();
}
protected DialogRunBase dialog()
{
DialogRunBase dialog = super(dialog, true);
;
dialogFieldCustVend = dialog.addField(typeId(NoYesId), "Show vendor?");
dialogFieldCustAccount = dialog.addField(typeId(CustAccount));
dialogFieldVendAccount = dialog.addField(typeId(VendAccount));
// We start out by disabling the VendAccount field
dialogFieldVendAccount.fieldControl().enabled(false);
dialog.allowUpdateOnSelectCtrl(true);
return dialog;
}
public void dialogSelectCtrl()
{
super();
dialogFieldCustAccount.enabled(dialogFieldCustVend.value() == NoYes::No);
dialogFieldVendAccount.enabled(dialogFieldCustVend.value() == NoYes::Yes);
}
You may also consider using radio button enabled field groups to control larger groups of fields. You can see an example of this in the AX 4.0 payment generation dialog.
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at https://www.microsoft.com/info/cpyright.htm
Comments
Anonymous
October 17, 2006
Hi Palle, your code running only when user select another control, this don't understand for begginer. I use "controlMethodOverload" way. public void dialogPostRun(DialogRunbase dialog) { ; dialog.dialogForm().formRun().controlMethodOverload(true); dialog.dialogForm().formRun().controlMethodOverloadObject(this); super(dialog); } boolean fld1_1_modified() { ; this.dialogSelectCtrl(); return true; } Best regards, ValeriyAnonymous
October 18, 2006
Valeriy, It is correct that my code will only work when you select another control. But if you need to control access to different controls in the dialog, it is highly likely that you in fact move to another control. However it would be nice to be able to react sooner. Your approach has the constraint that you have to make an assumption about what the physical control names will be in your dialog, e.g. "fld1_1_". If someone modifies that dialog and inserts any field before the field you have written code for, your code will break. So you need to be cautious applying this method, but granted it gives the wanted result.Anonymous
January 18, 2009
PingBack from http://www.keyongtech.com/319459-how-to-find-the-discussionAnonymous
June 17, 2009
PingBack from http://pooltoysite.info/story.php?id=5639