A bug in validation of methods' access modifiers and class abstract modifier

While testing the new feature of Tabax plugins today, discovered a bug in access modifiers validation.

It is performed only at compile time.
Which means, that if the compiler doesn't know what object the method belogns to, than the validation is skipped.
And you can run protected and private methods from whereever your code is executed.

Here is a simple example: (press cancel in the dialogs, otherwise you will get a RunTime error, because the method pack is not implemented in RunBase)

static void tutorial_AccessModifiersError(Args _args)
{
    Object runBaseObj;
    SysDictClass dictClass;
    ;
    runBaseObj = RunBase::makeObject(classNum(RunBase));
    runBaseObj.setInPrompt(true);
    runBaseObj.promptPrim();
    runBaseObj.setInPrompt(false);

    dictClass = new SysDictClass(classNum(RunBase));
    dictClass.callObject(methodStr(RunBase, promptPrim), dictClass.makeObject());
}

setInPrompt and promptPrim are both private methods. so they should not be allowed to be called this way.

The same thing can be achived by using DictClass.

The funny thing is:
while writing a test example for this post, I stumbled upon another bug - now it's about the abstract modifier of a class.

You all are probably aware that RunBase is an abstract class and cannot be initialized.
Well, in the example I showed this is done using 2 methods again :)

I guess someone should register these with Microsoft.

Tabax plugins' update - RecentWindows, RecentProjects

After developing 3 great tabax plugins I was feeling a little unsatisfied, because I wanted to add images to the popup menues.

AndyD has developed a class that allows me to do this now.

The project containing the class with the images is "shipped" separately. Depending on where you want to see images in your popups menues or not, you will be able to import it separately if you do.

Download:
You can use the following links to download the projects (version 0.1.1) and the MenuImages class.

RecentProjects v. 0.1.1 -download
RecentWindows v. 0.1.1 - download
Class MenuImages - download

Alternatively you can download them from their homepages on Axaptapedia.

RecentProject - homepage
RecentWindows - homepage

Screenshot: (RecentWindows)

AxPaint - make your DAX look cool :)

A couple of months ago I asked Alex Kotov from AxForum to modify a project he wrote for fun half a year ago or so. Today he sent me an e-mail with the project.

A short description of what the tool can do for you: :)
Basically, it just changes the backcolor of your DAX 3.0 (it does not work for DAX 4.0) installation.
You can choose a simple custom color you would like to use, or select an image from your hard drive to use as the background image.
you can select a couple of settings as well (ALL the settings are accessed by pressing Alt + S in DAX after launching the AxPaint form) - like stretching the image or using a 'transparent' background, showing your desktop (you have to set the image path to a specific location for that).

Nothing much, you'd say. But it sure is fun to work in DAX when a nice picture is seen in the background. :)

Installation instructions:

1. Unzip the archived files.
2. Place the .bat and .ocx files somewhere where you won't delete them accidently.
3. Run the .bat file, which will register the .ocx
4. Import the project into Dynamics AX - the project contains one form AxPaint.
5. Run the form. It will automatically hide from view. Press Alt + S to run setup.

Custom settings (my preference):

1. The image path is setup to C:\Documents and Settings\%username%\Local Settings\Application Data\Microsoft\Wallpaper1.bmp - this is the path to the current wallpaper in Win XP (without active desktop)
   
2. Show desktop (like Delphi) option is set in the setup dialog.
3. In the startupPost method of the Info class the following lines are added:  
4. An external application is used to change the wallpaper on system startup. So every day I have a different look in my DAX :)

Project archive download link:
download

Custom code for the info.startupPost method:

 if (curUserId() == 'ikash')
    TreeNode::findNode("Forms\\AxPaint").AOTrun();

Link to the external WallChanger application:
download

Screenshots:

• Screenshot 1 - Josie Maran
  
• Screenshot 2 - picture home - original wallpaper
• Screenshot 3 - Eagle - Delphi kind of look

3 Dialog extensions

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