Dynamics 365 FO / AX - thoughts on application development and customizations

Today we experienced something weird in AX2009. We have installed an application module in the AX in the VAR and VAP layers, and are making CUS-layer modifications that are customer specific. In the module a tablemap is used to be able to implement code once but for use on several tables. However we experienced a run-time error when we ran a form, that called the code on the table map. The kernel complained about a field having id 0. We searched high and low but couldn't find any reason for the run-time error that occurred. We then tried making a cus-layer edition of all the mappings on tablemap and voila, no more run time error. Weird. :0S

As of january 1st 2010, I am no longer employed by thy:data. I will be employed as a Senior System Consultant by Columbus IT Partner Denmark A/S situated at the office in Aalborg.

A colleague of mine needed to determine (runtime) what ax-tier his code was running on. We digged around, and he came up with the solution: if (isRunningOnServer()) { // Server } else { // Client } As a footnote he needed this check to make some code to refresh the AOS-code cache, when implementing quick-fixes to an environment running with multiple AOS-instances.

I've been assigned a task where the merge between VAR and CUS-layer of the application is necessary. I like to make my self a TO-do-list of elements to be processed, so I can check an item when it is done. I wrote a small job to identify elements in the application that were represented in both VAR and CUS-layers thus representing a potential layer-conflict. The job produces an info-log with the potential conflicts that can be copied in to Excel to be used as a TO-DO-list. static void JSOVarVapAndCusConflictsJob9(Args _args) { UtilIdElements utilIdElements; UtilIdElements VarVapUtilIdElements; Map elemMap; MapIterator elemMI; UtilElementType recType; RecId utilId; int pos; str 60 elementName; elemMap = new Map(Types::String,Types::String); while select UtilIdElements where (utilIdElements.utilLevel == UtilEntryLevel::cus) && UtilIdElements.parentId == 0 {

Recently I've had an assignment where we needed to "split up" a label file. The assignment was to: * read thorugh a label file. * If any labels were encountered with a number bigger then N these should be written to a new label file AND any references to these labels should be replaced in the code. So I exported all adjustments/code made to an .xpo file, and I took a copy of the label file. Then I wrote a class that did the "splitting up" of the label file and the search/replace of labels in the code (.xpo file). This made for use of an other entry in this blog, namely extracting text from a label, and for some interesting use of the TextBuffer object for search/replace. Here you can download the code. Use at own risk !!!

Put the following code in the GLOBAL class in a new method called setFormModal : static void setFormModal(int _thisHWND, boolean _bModal) {     DLL _winApiDLL;     DLLFunction _EnabledWindow;     DLLFunction _getTop;     DLLFunction _getNext;     DLLFunction _getParent;     void local_enableWHND(int _lHWND)     {         int lnextWnd;         lnextWnd = _getTop.call(_getParent.call(_lHWND));         while (lnextWnd)         {             if (lnextWnd != _lHWND)                 enabledWindow.call(lnextWnd, (!_bModal));             lnextWnd = _getNext.call(lnextWnd, 2);         }     }      ;     _winApiDLL = new DLL('user32');     _getNext = new DLLFunction(_winApiDLL,"GetWindow");     _EnabledWindow = new DLLFunction(_winApiDLL,"EnableWindow");     _getTop = new DLLFunction(_winApiDLL,"GetTopWindow");     _getParent = new DLLFunction(_winApiDLL,"GetParent");     _getParent.returns(ExtTypes:: DWORD);     _getParent.arg(ExtTypes:: DWORD);

Useful debugging tip for tracking down the point where an exception is thrown. Some times it can be difficult to determine where an exception is thrown. Is it e.g. the validatefield method on a data source field on a form that throws the exception, or is it the validatewrite method on the data source or even the validatewrite method on the table it self. A useful trick to establish the point in the code where the exception is thrown, is to set a break point in line 11 in the method add in the class Info. You can find the Info class at the bottom at the class subtree in the AOT. This will stop execution and activate the debugger each time something is added to the infolog which is normally done when an exception is thrown.