Saturday, August 24, 2013

No colors when comparing code in AX

This is just a quick post on one of the annoyances when comparing elements in AX after the installing the latest version of Internet Explorer 10. Our beloved compare form suddenly doesn't show the red and blue color any more.


Apparently the latest version of the browser, IE10, doesn't support the gradient filter (CSS in HTML) once used for displaying the left hand side color boxes.

While it's not that big of an issue, I still felt compelled to sort it out. First I tried using some standard gradient CSS picked up from ColorZilla, but ended up using just static colors. I got the gradient to show OK in the browser, but not in the Ax form. Anyway, I just wanted the colors and not the fancy effects.


The solution is easy. Just change the HTML code put in the ActiveX components. Comment out the fancy gradient stuff and put on your own red and blue. Here is how I did it:


If anyone feels like sharing a different solution, please comment. For all I know, this will be sorted when Internet Explorer 11 is released. :-)

Update 9th of September

This problem is now solved in CU6 (6.2.1000.1437). They made the HTML complete with a CSS style section. I guess someone didn't want to throw out the gradient effect. ;-)



Monday, August 19, 2013

Compare models using PowerShell

I wrote this post about how to use PowerShell to compare two modelstores based on installed models. It is a simple comparison and only checks if the two have the same list of models.

In this post I will show how you can compare the list of elements in two models. This will only compare the actual list of elements, and not their metadata or code.

The Get-AxModel PowerShell command allows us to load both the Summary and Details of a certain model. It will list out information like the Name, Path, ElementHandle and ParentHandle, just to name a few.
First let us have a look at the Summary and Elements property, then later I will show how we can use the Compare command to easily compare two lists and pull out any differences.

For this example, I have created a small model named "MyModel" and added an EDT, a table field and dropped that field into a Grid in a form. I also made a private project for this model.
If I list out the Summary of this small model it would display this:

(Get-AXModel -Model "MyModel" -Details).Summary

Output




If I want to see a list of all the elements, I can run the same command but instead of the Summary I load the list of Elements:

(Get-AXModel -Model "MyModel" -Details).Elements | select path, elementtype | Format-Table -AutoSize

Output



Notice I explicitly select the path and elementtype, and just to make the output a bit prettier, I throw in a formatting statement in the end, Format-Table -AutoSize.

Now, I exported my model to a file (C:\mymodel.axmodel) and then added some additional elements to the model inside of AX.

I then compared the elements from the file with the model elements in the actual modelstore:

compare `
 -ReferenceObject ((Get-AXModel -Model "MyModel" -Details).Elements | select path, elementtype) `
 -DifferenceObject ((Get-AXModel -File c:\mymodel.axmodel -Details).Elements | select path, elementtype) `
 -PassThru -Property path, elementtype | sort path | Format-Table -AutoSize

Output


Notice how it list the SideIndicator to the left hand side, or the ReferenceObject list. Apparantly the model has a couple of elements more compared to the file. Yes, you can list out the elements from a file as well, as mentioned in this blog post. Again, it will not compare X++ code or metadata. Maybe in future versions, Microsoft will add a checksum or something we can compare for possible differences between two elements.

Finally a quick tip for loading long list of elements. If the list of elements grows beyond the height of the buffer, you will only see the last part of the list. You can "fix" this by increasing the Screen Buffer Size under Properties.


Enjoy!

Saturday, August 17, 2013

Logging Infolog to Event Viewer

This is probably a bit far fetched in real life, but still a cool feature built in AX 2012, and I really wanted to make a new blog post after a long summer vacation. Maybe someone will enjoy it still. :-)

This is already explained on the MSDN article "Propagate Infolog Messages to the Windows Event Log [AX 2012]", but I thought I'd throw in some screenshots just to make it even more appealing.

Obviously, this will only log client side as the Infolog push its messages to the client, and this tracing feature runs in the client scope.
There are some options to introduce server side logging using for example log4net. It is pretty good covered in this blog post, but it would require rewriting X++ code in order to trigger logging.

Developers will have the ability to use the static Debug::printDebug()-method to push any string to the debugger output window. These messages will open up the debugger, unless it isn't already running, and unless the output window is hidden, it should reveal the strings on the Debug-tab. Remember, in AX2012 only the users who are in the local (machine) usergroup named "Microsoft Dynamics AX Debugging Users" will see the debugger, as explained here.

Anyway, let us have a look at the easy and quick logging of Infolog messages.

1) Start by locating the ax32.exe.config file, normally located under "C:\Program Files (x86)\Microsoft Dynamics AX\\Client\Bin\"


2) Open the file in notepad and add some additional XML sections in order to trigger the functionality. You can copy from the MSDN article or just type in what I have used.

3) In order to test this, let us create a simple job that triggers a Info, Warning and Error message.


4) Then let us open the Event Viewer and filter the log, just to focus on the events we just created.


4) Notice the Info-message was not included in my example, due to how I defined the switchValue only to include warnings and errors.


Now imagine having this set on a busy terminal server where everyone would be using the same logging setting. Depending on your requirements you could use this to preserve the most recent warnings and errors thrown to the client and browse through them when end users complain about all sorts of "mysterious" errors. Who haven't experienced end users complain about an error they can't remember the content of? Now you can go back and look in the Event Viewer and find it - hopefully.