Wednesday, May 21, 2014

How to use recursion to loop over form controls using object type

This was a stackoverflow answer I provided that neatly displays a way to loop over all form controls using recursion and the object type.  This may be useful when you want to modify/initialize form controls systematically.

Tuesday, May 20, 2014

Reflection on AOT to get delete actions

We are in the middle of an AX 2009 to AX 2012 upgrade, and part of our upgrade steps was to first import our AX 2009 AOT schema only.

During this process we weren't able to bring over the delete actions, so I wrote a quick job to reflect on the AOT that I could use to identify missing custom delete actions.  I think it's a good example of some simple AOT reflection.

Friday, May 9, 2014

HowTo: Update all Cross Reference (XRef) data in batch in 1 line of code in a job! (AX2012)

AX2012: To update your Cross Reference data (XRef) data in your system in BATCH in one line of code, just create this job and run it:

static void updateXRef(Args _args)
    xRefUpdateIL::updateAllXref(true, false, true);
    info('Updating XRef batch job added!');

It will add a batch job and start working.

Note: I'm running AX 2012 R2 CU7.  I'm not sure if this exists in previous AX 2012 versions.

Walkthrough: Detailed steps to creating your own useful AX custom best practice check and custom attribute! Quick & Dirty

I am a big proponent of using tools to systematically perform checks to ensure consistency and quality instead of relying on human intervention, so naturally I am a big fan of writing code to check my code!

I call this quick & dirty because I won't be going deep into some details and will let you investigate on your own.

In this walkthrough I will be showing you both directly and indirectly how to:

  • Create a custom attribute
  • Create a custom Best Practice Check
  • Reflect on the AOT to see if an object has that attribute
  • Throw best practice warnings in the compiler
  • And more!


This is proof of concept code which is demonstrating these concepts in the simplest way, but you should use these concepts and refactor them to follow best practices such as using labels, EDTs, etc.  You should also create new methods for commonly used blocks of code.  You can take these concepts and expand them to real-world uses too.

Create the custom attribute:

Create a class and name it "MyCompanyAttribute" and extend SysAttribute.  Add a member variable "int feature;" to the classDeclaration.

class MyCompanyAttribute extends SysAttribute
    int feature;

Add an accessor method to get the feature value.

public int feature()
    return feature;


Create the new() method. This method is important to assign the variables, and XML documentation is crucial here too for intellisense to display to developers.  Note that I default "feature = 0" in the arguments so that it will make this parameter optional.

Intellisense will look like this:

/// <summary>
/// Initializes an instance of the <c>MyCompanyAttribute</c> class
/// </summary>
/// <param name="_feature">
/// Internal company feature number for customization tracking
/// </param>
/// <remarks>
/// This attribute should be used on custom methods added to base classes
/// </remarks>
public void new(int _feature = 0)

    feature = _feature;

Custom attribute done!

Add Best Practice Check and hook:

The class `\Classes\SysBPCheckMemberFunction` is what checks all member functions.  I will be limiting the code to strictly only checking class member functions in the CUS+ layer.

First create your new method that does the work:

protected boolean checkMyCompanyAttribute()
    boolean         ret = true;
    UtilElements    utilElements;

    switch (SysDictMethod.utilElementType())
        case UtilElementType::ClassInstanceMethod:
        case UtilElementType::ClassStaticMethod:
            // Find the lowest layer this object exists in
            select firstOnly RecId, UtilLevel from utilElements
                order by UtilLevel asc
                where utilElements.parentId     == SysDictMethod.parentId()
                   && utilElements.recordType   == sysDictMethod.utilElementType()
                   &&         ==;

            // If the lowest layer is CUS+ then we want our custom checks enforced
            if (utilElements.utilLevel >= UtilEntryLevel::cus)
                // Now check if the attribute is not decorating the method
                if (SysDictMethod.getAttribute(attributeStr(MyCompanyAttribute)) == null)
                    // Developer has failed the BP check!  Let them know
                    ret = false;

                    // This is what puts the BP error in the compiler window.
                    SysBPCheck.addError(0, 1, 1, 'MyCompanyAttribute: Missing custom [MyCompanyAttribute] on custom CUS+ layer method.');


            ret = true;

    return ret;

Then in `\Classes\SysBPCheckMemberFunction\check` this is where you put your hook to call your BP check.

MS Best Practice Note: If you were to do this for a customer or in a live system, you should really create an EDT(s) and parameter(s) on `\Data Dictionary\Tables\SysBPParameters` then add them to `\Forms\SysBPSetup` so that users can enable/disable them.

Final Steps to get it picked up and active:

Turn on Best Practice Checks if you haven't already! See for detailed directions or the abbreviated directions are just set your compiler to "Level 4"

You may need to recompile `SysBPCheckMemberFunction` or better yet just compile forward `\Classes\SysBPCheckBase`.

You may need to close/reopen your compiler and/or client too.  When the compiler window is opened, it builds various maps.


It works!  It should error on your new custom method.

You will notice a purple underline on the method too:

Let's add our attribute and recompile the class (not just the method) and resolve the BP check:

Closing Notes:

In my code, I used error code 0, which doesn't appear to be used by Microsoft.  You should really define a new macro definition and error code in `\Macros\SysBPCheck`.

The error code appears to be used for two things.

  1. Obvious: Provide an easy error code # to look-up instead of searching the error string, especially if the string is truly something like `Error on %1` where the string changes depending on the code.
  2. Not so obvious: `\Classes\SysBPCheck` builds an ignoreMap(ErrorCode[int], Paths[Set of strings]) and the error code is the key.
I recommend prefixing your error message with something (like "Alex:" )to clearly identify your BP check as custom, especially if your BP check has a bug or scenario you hadn't anticipated and is mistakenly being thrown.

A comment on reusing the same error code.  If you throw the same BP error on the same method/line/column, it will only take the last one.  The same error can't happen twice on the same method/line/column logically so this makes sense.  So because of this, if you use (0,1,1) for the first three parameters and just change the error message, sometimes when you intend to display multiple messages, only one will appear.

Ignore rules: 

If you have some specific objects you always want excluded, you can add them to `\Macros\SysBPCheckIgnore` and make sure your error code is added in `\Macros\SysBPCheck`.

Alternatively, you can just create a custom Set of paths then union them to the ignoreMap created in `\Classes\SysBPCheck\initIgnoreMap`.

Monday, May 5, 2014

Difference between "modified" and "dataChanged" form data methods on datasource fields

When overriding methods on a form data object, it is important to know what they do exactly!  Two methods in particular, formdataobject.modified() and formdataobject.dataChanged(), sound very similar but are different.

The important difference is that dataChanged() runs EVERY time the data is changed, while modified() only runs after successful validation!

This may seem like a "duh" post for some, but I was surprised at the number of people who couldn't tell me the difference.

So if a user changes data on a form, it may fail validation and modified() would never run.  This is often where you would prefer to hook your code since if the field doesn't truly change, you don't want anything triggered.