This one is a short blog post to index a few hands on studd when working with grids

  • To enable multiple row selection on the grid, set the property 'MultiSelect' to Yes
  • To display a checkbox along with each row to remember each row selection, set the property 'ShowRowLabels' to Yes
  • Code to get the currently selected rows: tableName_ds.recordsMarked().lastIndex()

For quite some time, I was looking for this answer ? What benefit in the world does multiple models give ? I just could not figure it out from the basic definitions available at most of the places

model is a set of elements in a given layer. Each layer consists of one or more models. Each layer contains one system-generated model that is specific to that layer. Every element in a layer belongs to only one model. In other words, no element can belong to two models in the same layer, and every element must belong to a model.
There we some questions that kept arising all the time

  • Is the end user suppose to switch in between the available models ?
  • If two or more models can be operational, what in the world is is the significance of the current model
And so many more, it was all too frustrated. To my surprise, most of the available developers and consultants were even not able to clear my concept of the purpose of multiple models side by side. To my luck, I came across a convergence video about models and metadata architecture. There, the presenter cleared it all away. 

Actually models are providing a way to export customizations (from say development or staging environment ), import them in another environment (production) without disturbing as many models already installed from n numbers of ISVs and vendors. 

Let me explain the concept with an example. Lets suppose you being an end user have a customization deployed in your production environment from vendor A, on the form, say.... Vendor List Page. And those customizations has additional menu buttons in the Action Pane. Now you bought another solution which has other customizations on the same form. Now you already have the Vendor form customized in, say VAR layer and the new vendor is also developing customizations in VAR layer ? So how would the two different versions co exist now ? How would the same element on the same layer have 2 different versions with end user expecting to get the new customizations without disturbing the already deployed customizations. This is where models come to play :) 

Since each layer can have multiple models, or slices if you ask the framework developers, each vendor can now produce their own model, install at the same layer, and both co exists meaning 2 different model customizations will be available at run time for the end user. This has questioned both of my questions actually since the current model is for developers and not for end users and that all models on respective layers render on runtime shadowing the layers  underneath.

Dynamics AX 2012 Workspace titile and the Info Class

maqk® by MolviDSLR Khan | 10:30 AM

The Info Class has a very special place among the classes provided by the AOT to work with. It is a framework class that mainly deals with the information, warning, or error messages shown by the AX client, Infolog in other words. All the infolog messages displayed on the AX client are constructed using the Info class.

However the InfoLog also has methods and attributes to handle the Dynamics AX workspace window. This post will describe a few cases where the Info class can be used besides creating and displaying an infolog. The most obvious one being the target of this post: Show the active configuration in the main window title bar.

As we discussed in a post earlier, we needed to have the same client connected to various server configurations. And we created multiple shortcuts of the client, and using command line parameters, appended the regConfig command with each shortcut's Target property and their you go, same client with two different shortcuts connecting with two different server configurations. 

However, since the client is the same, we needed to have some text value or string representing each client's active configuration so that we can comfortably identify which instance we are currently working on. This can help a lot while working on both the environments side by side. Here comes the Info class to play. 

We need to append the active configuration name with the window title. And we all know their should be no rocket science involved in it and their is none.

A child's look at the Info Class :)

Dynamics AX 2012 > AOT > Classes > Info: A child's look :) 

We see that the class contains a few methods that are triggered on the respective events. We are mainly interested in the workspaceWindowCreated method.

This method is executed when the workspace window is created. And we have an integer _hWnd handler parameter through which, we can refer to the created window. All we need to do is to add the following lines to the code;

void workspaceWindowCreated(int _hWnd)

    // Put workspace window specific initialization here.
            WinAPI::getWindowText(_hWnd) + " - " + 
            xInfo::configuration() + "");


A few interesting links about the Info class that I could google out are provided;

This error appeared in our environment when we started importing configuration files for bulk deployment. You can export a working configuration so that the same can be distributed to n number of clients. 

Exporting the working configuration from one environment and re-importing in another gave this error on one of the clients.

Microsoft Dynamics AX Error
An invalid directory structure for Microsoft Dynamics AX was detected. The subdirectory C:\Program Files (x86)\Microsoft Dynamics AX\60\\Client\bin does not exist.

To my surprise, the path mentioned in the error, "\Program Files (x86)\Microsoft Dynamics AX\60\\Client\bin" never existed at the client I was working on. Why would this false path generate from this client ? Left curious at my place, I googled the same and came accross the post: 

As rightly mentioned in the post, you need to fix the registry. These configurations are actually stored in the registry. The config executables modify the registry entries actually. And from there, the client or the server reads and loads accordingly. A different client directory path in the original configuration (exported from) will propagate in all clients with imported configurations. At this error, check the registry at the path:
HKEY_CURRENT_USER\Software\Microsoft\Dynamics\5.0\Configuration\Original (installed configuration)
 and look for the directory, bindir and datadir values.

What actually happened is that the client initially configured [and configurations exported from there] had its client installed in the \Program Files (x86) folder. However a few other clients were in the \Program Files folder. Now exported configurations are totally dependent on the original system paths and directories. Hence the initial system path propagated and didn't get checked in the middle. 

Perhaps we can have system variables representing the AX client path and AX server path and other significant locations so that such issues are mitigated.
A scenario at our end required to have the same client able to connect to multiple AOS server instances, say DEVELOPMENT, TEST and PRODUCTION environments. One way is to have multiple client configurations, and toggle them to the desired server configuration when needed. See the image below;

Dynamics AX Client configuration utility

However for more ease of use and friendly behaviour, we can have a single client with multiple shortcuts each toggling the client configurations on run time based on command line parameters :) But to successfully do this, we obviously need to know the command parameters we can attach to the AX client executable [AX32.exe]. So here we go;

Client configuration commands [AX 2012]


Now with the information from the above link, we come to know that regConfig is the parameter we can provide with the AX32.exe to mention the client configuration name the client will run accordingly. A sample command is compiled as follows;

ax32.exe -regConfig=ConfigName

You can test the above command with correct configuration names from the Run command box [Windows+R] and can play with it too :)
Try to provide an incorrect configuration name and see what happens. Try giving a wrong command and notice the behaviour.

Coming back to the topic, what we did was to have two different shortcuts, each with its own command line parameters
  • Client 1 - "AX32.exe - regConfig=YourFirstAOSClientConfig"  
  • Client 2 - "AX32.exe - regConfig=YourSecondAOSClientConfig"  

See the image below;

Now both the shortcuts are pointing to the same single AX32.exe but with different values in the parameter '-regConfig' thus directing the client to connect to a different client configuration from the default one. Now these configurations can be a copy of each other or associated to the same server with different databases or entirely different AOS servers, this is entirely up to you how you need it :)