Help content for Microsoft Dynamics AX 2012 is now available on TechNet

As you might have heard, AX 2012 has RTM'ed recently.
Now, the question you might ask is - OK, I have read the What's new in AX 2012, but that's not enough. The changes are too vast and I need more detailed information about them.

Well, worry no more :)

The information about AX 2012 is now available on TechNet, with a lot of new content still being added each day. And, finally, it's actually interesting to read. We now have various graphs, diagrams and tables that should help you understand each feature area a bit better.

Hint: The description of the functional modules of the application is under section 5. Use Microsoft Dynamics AX.

Enjoy!

Microsoft Dynamics AX 2012 Technical Library
http://technet.microsoft.com/en-us/library/gg852966.aspx

Tutorial: Table Relation properties in AX 2012

As many of you already know, Microsoft has put in a lot of effort into normalizing the tables in AX 2012 and consolidating all the data modeling tools in one place - the table itself. As part of this effort, a number of new properties have been introduced on Tables, and in this post I would like to cover some of them, namely the properties on Table Relations.

The new properties you will find on a Table Relation in AX 2012 are:

• Cardinality
• RelatedTableCardinality
• RelationshipType
• Role
• RelatedTableRole
• UseDefaultRoleNames
• CreateNavigationPropertyMethods
• NavigationPropertyMethodNameOverride

Hua Chu from the AX team has written a Guideline document, explaining how these properties should be set for Relations you add to Tables in AX. Note that in AX 2012 most of the above information is not actually used at runtime. This is something that will happen in future releases.
I have modified the document so that it contains the information relevant for partners and customers extending the standard application and have uploaded it to my OneDrive.

The document requires certain knowledge of Entity Relationship Modeling (ERM) and UML notation.

Disclaimer:
This document is intended as a guideline only, and should not be used as a Step-by-Step instruction.
Changes to any of the described functionality might still happen before AX 2012 RTM.


Your feedback and questions are, as always, welcome.

Tutorial: lockWindowUpdate() vs. lock()/unlock()

There are two method pairs in X++, that are used throughout the application by everyone writing some processing on application forms. These are:

element.lock();
element.unLock();

and

element.lockWindowUpdate(true);
element.lockWindowUpdate(false);

Now, not that many people know the difference between the two methods, and only very few think about why and when should each of them be used.
I will try to describe the behavior of these methods and at the end give some recommendations on how to use them. I have done some kernel code reading (with help of kernel dev. Andy Stach, who I would like to mention here), so what I write below is more or less backed up by code.
If you disagree with some of the recommendations though, please share your experience in using these methods through comments for this post.

FormRun.lockWindowUpdate()

is basically a wrapper around the LockWindowUpdate Win32 function. What it does is pretty simple:

When a window is locked, all attempt to draw into it or its children fail. Instead of drawing, the window manager remembers which parts of the window the application tried to draw into, and when the window is unlocked, those areas are invalidated so that the application gets another WM_PAINT message, thereby bringing the screen contents back in sync with what the application believed to be on the screen.

See the link on MSDN for a detailed description.
Note, that according to MSDN, it should not be used for general purpose suppression of redraw operations, but only when dealing with drag&drop operations. This does not hold true for AX, where this method is used all over the place to prevent redraw of controls on the form.
Another interesting point is that only one window can be locked at the same time. So, any nested calls to lockWindowUpdate will be ignored, but when unlocking, only the outer-most unlock will actually invoke the Win32 counterpart. Now, I have not seen this used in X++, which is for the better.

FormRun.lock()

is internally invoking lockWindowUpdate to prevent the redraw of the window, and then also prevents the IntelliMorph control layout engine from running. This is commonly used in scenarios where control properties affecting control arrangement are being set in a loop, which provides a performance optimization as it avoids redundant arrange calls being processed. On the other hand, when calling FormRun.unlock, more work will need to be done, compared to using lockWindowUpdate(false), where the control layout changes were actually processed by the layout engine, but simply not displayed.

So, based on my investigation, I would suggest to use the following recommendations when doing form development:

• When formRun.resetSize() is used, specifically, when some controls become visible, increasing the form size, always use formRun.lock()/unlock(), otherwise the change in the size of the form might not get reflected on the screen correctly.
• When changing multiple layout properties (Left, Width, etc.) on one or more controls, use lock/unlock
• When you modify the properties that do not impact the layout of controls on the form, use formRun.lockWindowUpdate(), or, if there are only very few control properties being modified, do not lock the form window at all.

Microsoft Dynamics AX 2012 Beta now available for download - please share your feedback

As some might have noticed, I was quiet for quite some time now. I won't go into much detail as to why. What I want to say is that I along with a number of dedicated people have been hard at work on the release of a solution for Process Manufacturing and Distribution industry, which is also available in Beta through the below links.

Those of you working in this industry, I would be grateful for your feedback on our work so far, as well as any bug reports or design change requests for the RTM version or future releases.
Any other feedback, especially on the development tools and environment, is also welcome, of course.


Virtual Machine: 

https://mbs.microsoft.com/partnersource/marketing/marketingcollateral/demos/AX2012DemoToolsMaterials

https://mbs.microsoft.com/customersource/downloads/servicepacks/AX2012DemoToolsMaterials

Installable bits (ISO & IS IExpress pkgs):

https://mbs.microsoft.com/customersource/downloads/servicepacks/AX2012Beta

https://mbs.microsoft.com/partnersource/support/selfsupport/productreleases/AX2012Beta

MSDN Dev Center:

http://msdn.microsoft.com/en-us/dynamics/ax/gg712261

TechNet Library:

http://technet.microsoft.com/en-us/library/gg852966(v=AX.60).aspx

Tutorial: Undocumented behavior of kernel functions min()/max()

I was recently reviewing some code written to be shipped with AX6, and noticed an unfamiliar pattern being used in it. I investigated a bit deeper, and turns out it actually works fine on previous versions of AX as well.


I am talking about 2 kernel functions for finding the maximum or minimum of the specified values.
The signature of these methods is shown on the below image:



As you can see, it takes 2 arguments of anytype, and returns an anytype which is the largest of the two values. But it can accept much more than 2 arguments, even though it is not documented as such.

I wrote a small job to showcase this behavior. The code is provided below. You can also download it from my SkyDrive Dynamics AX share.

static void Tutorial_MinMaxFunctions(Args _args)
{
    #define.ArraySize(11)

    Random  rand = new Random();

    int     counter;
    int     arrayInt[#ArraySize];
    str     arrayIntAsString;
    int     arrayIntMaxValue;
    int     arrayIntMinValue;
    ;

    for (counter = 1; counter <= #ArraySize; counter++)
    {
        arrayInt[counter] = rand.nextInt();
        if (arrayIntAsString)
            arrayIntAsString += ', ';
        arrayIntAsString += int2str(arrayInt[counter]);
    }
    info("Generated array of integers: " + arrayIntAsString);

    info("The typical way to find a maximum is by looping through all the values one by one, calling the comparison function multiple times");
    arrayIntMaxValue = minint();
    arrayIntMinValue = maxint();
    for (counter = 1; counter <= #ArraySize; counter++)
    {
        arrayIntMaxValue = max(arrayIntMaxValue, arrayInt[counter]);
        arrayIntMinValue = min(arrayIntMinValue, arrayInt[counter]);
    }
    info(strfmt("Max.value: %1 and Min.value: %2", int2str(arrayIntMaxValue), int2str(arrayIntMinValue)));

    info("Using max and min with 11 arguments works just as well");
    arrayIntMaxValue = minint();
    arrayIntMinValue = maxint();
    arrayIntMaxValue = max(arrayInt[1], arrayInt[2], arrayInt[3], arrayInt[4], arrayInt[5], arrayInt[6], arrayInt[7], arrayInt[8], arrayInt[9], arrayInt[10], arrayInt[11]);
    arrayIntMinValue = min(arrayInt[1], arrayInt[2], arrayInt[3], arrayInt[4], arrayInt[5], arrayInt[6], arrayInt[7], arrayInt[8], arrayInt[9], arrayInt[10], arrayInt[11]);
    info(strfmt("Max.value: %1 and Min.value: %2", int2str(arrayIntMaxValue), int2str(arrayIntMinValue)));

    info("Note that comparing an integer and a real also works, as well as outputing the results straight into an infolog message");
    info(max(12, 12.001));
}

Another interesting point is that it can actually accept different types of arguments, for example, a real and an integer, as shown above. And it actually returns an anytype, which implicitly gets converted to a string when sent to the infolog.

Disclaimer: Since this is not a documented feature, it can theoretically change in the future releases, but I doubt it in this particular case.