The Task Recorder, your friend in tutorial need

Yes, Ax comes with a manual. And yes, they have become better over the years. But then and now, there always was the need to create custom help documents for users.

Standard Ax now comes with a real friend in need: The Task Recorder.

What it does? Record all your actions in Ax, creating screen shots included.

How it works? Easy.



Open the Task Recorder form. You can find it under the Tools menu, Extra option.





Press the red button on the left to start recording. (pretty old skool huh?)


Then just perform the tasks you want to cover in your instruction set. For example go to the AR module, open the customers form and create a new customer. Perform the necessary steps to create a new customer account.


When you're done, press the second icon from the left on the Task Recorder to stop recording. That's all folks.


Now when you want to create a nice document explaining the process of creating a new customer, you use the icon on the right in the Task Recorder. You get an overview of all recorded tasks. Use the button Generate document to let Axapta generate a complete Word document, containing screenshots, navigation instructions, headers and so on. Yes, it's that easy and that fast!



This nifty little tool was previously only available for partners through Partnersource, but in Ax 2009 SP1, it is generally available in standard Axapta.


So, what are you waiting for? Go create those tutorials.





Greetz,





Willy

Forms forms forms

Microsoft constantly works on the look and feel of its software. So does Axapta change appearances. Sometimes for the better, sometimes ... not so.
What I personally do not like in Ax 2009: All those different forms, creeping out of the current workspace. Your Windows menu bar really gets crowded like that.

If you are like me and want your Axapta forms to stay in the Axapta workspace, there is a little thing you can do.

Change the Class SysSetupFormRun , add this little line of code before the super call of the init method:

if(this.form().design().windowType()==FormWindowType::Standard)
this.form().design().windowType(FormWindowType::Workspace);


Now that's better, isn'it?


Greetz,

Willy

Dynamics Ax Build numbers

When running multiple Axapta installations, it's always important to know the right version number of your client, AOS and application. You do not want to mix different versions.

Here is a short reminder of versions:

Dynamics Ax 2009

Ax 2009 RTM 5.0.593.0
Ax 2009 SP1 5.0.1000.52

Dynamics Ax version 4
Ax 4 RTM 4.0.1659.26
AX 4 SP1 4.0.2163.0
AX 4 SP1 DIS hotfixes 4.0.2500.XXX
AX 4 SP2 4.0.2501.116
AX 4 SP2 DIS hotfixes 4.0.2503.XXX

Axapta version 3 - Application
SP2 514-90
SP3 514-193
SP4 514-320
SP5 514-513

Axapta version 3 - Client
SP1 1951.17 (1951.18)
SP2 1951.2410
SP3 1951.3730
SP4 1951.4060
SP5 1951.5160

Check you version number in Ax with Help - Info.
In Axapta V3, the information is in this format: client version/application version/localization version.

Greetings,

Willy

AOS instance name not displayed correctly

You might think that with Axapta, just like in real life, the same rules count: Don't believe it until you've seen it with your own eyes. But even then, it is not always true.

Look at following scenario:

You have 2 AOS instances on 1 server.

AOS1 - Port 1 - Server 1

AOS2 - Port 2 - Server 1

Now you setup your client configuration.

But you get distracted and enter some wrong info in the optional fields.

In the Instance name field, you set AOS1. But in the optional Port field, you enter the port number for AOS2, so Port2.

You start your client, check the AOS instance in the status bar at the bottom right and...

What you see is not the truth. The status bar reads 'AOS1', but in reality, the optional port number has been used and you are connected to AOS2. Pretty misleading, not?

But do not believe me, do not believe Axapta, check for yourself.


Willy.

Reading a webpage with Axapta

There seems to be no limit to what you can do with Microsoft Dynamics Ax, aka Axapta. For instance, reading a webpage.
In the old days (version 3), this was possible using the WinInet class.
In Ax 2009, just use CLR interop (common language runtime interoperability).
For example:

static void WebClient(Args _args)
{
System.Net.WebClient myWebClient;
System.IO.Stream myStream;
System.IO.StreamReader myStreamReader;
str content;
str myURL="http://www.microsoft.com/dynamics/ax/default.mspx";
;
myWebClient = new System.Net.WebClient();
myStream=myWebClient.OpenRead(myURL);
myStreamReader = new System.IO.StreamReader(myStream);
content=myStreamReader.ReadToEnd();

info(content);
}

This is just a small example to get you started, start building on this base.


Greetings,


Willy.

The end of the AOD file as we know it

Mfp has shed some light on the new version of Dynamics Ax, version 6.
Major change from technical point of view: The aod files (Application Object Directory) are moved into an SQL database. So in time, say goodbye to axsys.aod, axsyp.aod and so on.
One of the advantages: Speed (for example when performing searches in the AOT).

You can read more about it in his post over here.