Skip to main content

Showing hidden fields in the table browser

A request for the possibility of showing the contents of hidden fields in Ax tables, using the table browser, made me do a google search, to avoid reinventing the wheel.

Sure enough Vilmos Kintera had adressed the problem earlier on http://daxrunbase.blogspot.dk/2010/04/non-visible-fields-in-table-browser.html. And he has done good work. :) Keep it up Vilmos.

Running the customized table browser seemed to work fine in AX 2009, however I ran into issues using it in AX 2012. I tested the customized table browser on the table CustTrans, which was the table I first found to contain hidden fields and I got a run-time error.

Investigating the problem I found that the reason in seemed to run fine on AX 2009 (using CustTrans table) but failed in AX 2012 on the same table, was due to a small issue that Vilmos hadn't adressed, namely Extended Data Types defined as Arrays.

The .ds datasource on the SysTableBrowser form had it's active method customized to populate the new lower grid, with rows showing the contents and "identity" of each hidden field. The method contains a switch case construction takling care of all intrisic types, and the default (no type found) simply attempts to convert the field value of the field in question to a string. However the issue was that fields based on Extended Data Types defined as arrays were not handled causing a run-time error.

I hacked this to make a further branch in the default case, checking if the arrayindex of the field in question is greater than 1, indicating that the field is based on an EDT defined as an array. If the field in question is an array, the hack iterates each array element and creates a row in the lower grid for each found array element.

The reason why everything seemed to work fine i AX 2009 was that DIMENSION fields were EDT's defined as arrays but in AX 2012 everything changed regarding financials dimensions, as you might know. In 2009 and previous versions Dimension fields were never hidden, as they were of course used. But in 2012 the old Dimension-fields are prefixed with DEL_ and put in the Obsolete... configuration key to be deleted in next upgrade.

The problem I encountered in CustTrans were due to the abovementioned. The customized table browser ran fine in AX 2009 because the Dimension field was in use and not hidden. However in AX 2012 this was not so, so the code could not handle the hidden Del_Dimension field (or indeed any array based field).

However the code WOULD have failed in 2009 also if anyone had browsed a table with a hidden array field. I tested this by setting the visible property of the Dimension field in an AX2009 to false, and browsing with Vilmos' customization and the result was a run-time error.

So here is my own modified version of Vilmos' tablebrowser.

AX 2012 - .xpo-file

AX 2009 - .xpo-file

Disclaimer: Use this code at own risk !!! This blogger can in no way be made responsible for data loss or damages that follows using this code.

Comments

Popular posts from this blog

Suppressing the infolog

Supressing the infolog is often useful in D365FO when augmenting code. When augmenting code using COC (Chain Of Command), you can have new code run either before or after the code you are augmenting. This means that any infolog-messages that the standard application code does, will be shown to the user, even if your augmentation supports a scenario where there must be no infolog-messages. How do you avoid the standard application infolog-messages ? To the rescue comes temporary supression of the infolog. The suppression consists of: 1) Saving the current infologLevel 2) Setting the infologLevel to SysInfologLevel::None 3) Run your code 4) Restoring the saved infologLevel to the infolog For example a table could have a validatewrite-method that validates that you are only allowed to use 3 out of 6 options in an enum-field, and you need to allow for a fourth one. Table a - validateWrite method: boolean validateWrite() {     Switch (this.enumField)     {         boolean ret;         case

Dynamics ax 2012 traversing selected records in a form data source

A classical developer challenge in Dynamics AX is to enable a form button when multiple records have been selected in the form by the user. This usually involves writing some form of loop (for or while or do-while) that starts out with calling _ds.getFirst() and continuing the loop as long as _ds.getNext() returns a tablebuffer. Well things got a little bit easier in AX 2012. In AX 2012 you can use the MultiSelectionHelper class. One example is the following that I encountered in AX 2012: Can you make the customer collection letter print out run for each selected collection record in the Print/Post collection letters form (Accounts receiveable / Periodic / Collections / Print/Post Collection letters). If we ignore the possibility for setting up print destination for running each report we can do this in two steps: 1) Change the "Multiselect" property of the "MenuButton" and the "Menuitembutton" in the MenuButton in the form from "Auto&quo

Subtle but important difference between _ds.executeQuery() and ds.Research()

This is actually an old entry. Been tumbling with a problem for the last few days. A form in our Dynamics AX module for Preventive Maintenance Control was not behaving. The form has "explicit" filter fields that the user can see without having to activate the form filter (CTRL+F3), for setting up filters most commonly used in an easy way. And this is working ok. However at this customer site, the form has been adjusted so that the user can have the form refreshed automatically periodically, and when the users at the customer site were making use of the "explicit" filter combined with the AX's normal filtering (CTRL+F3), the form simply threw away the normal form filtering. I discovered a subtle but very important difference between writing _ds.executeQuery(); (which was the way our code was doing it) and _ds.Research(); The difference is that _ds.Research() will retain the filter ranges in the forms query as they are right now. _ds.executeQuery() will NOT. It