DEV_SysTableBrowser version 2.0 is out!

I have been asked by a number of my blog readers to move this tool to Dynamics AX 3.0, so here is the updated version of this tool. Now it works on both DAX 3.0 and 4.0 (tested on 3.0 SP5 KR2 and 4.0 SP1 and SP2).

Also, I added a couple of things I considered useful to this new release:
- The user field select dialog option has now, by default, all the non-system fields selected, so that users don’t get surprised when no fields are selected. I agree – it does look strange :)
- Now it’s possible to select display methods along with table fields in the user field select dialog. This feature was already working with FieldGroups, so I decided it could be a nice add-on to the User Field List option
- I also fixed a couple of old (and new, brought to us by 4.0 SP2) bugs that existed in the tool
- After reading some of the last posts on AxForum, I decided to add the ability of browsing temporary tables into my project as well, so that others may use them if they want :) (this will also include browsing temp tables data shown in forms from Tabax when the next version comes out)
- Now you can also use the browser for debugging purposes, launching it from code (this works for temp tables as well). Just write:

SysTableBrowser::browseTable(table.TableId, table);

where table is a cursor (second parameter can be omitted for non-temp tables). In this case the browser will open and code execution will stop until you close the browser (if not in a transaction). Third parameter controls if code execution should be stopped.

- There are two variables in method new of class SysTableBrowser
saveQueryRun = true; // Enables/Disables queryRun saving when new options are specified
savePosition = true; // Enables/Disables cursor position saving when new options are specified

The options allow to save the user filters and cursor position when changing setup options.
Both operations could result in performance problems on large tables.
If that happens (or you just don't need them), just turn them to false. :)

The download link is: DOWNLOAD

See extended installation instructions and tool description on: HOMEPAGE

What was a little disappointing is that a number of bugs I wrote about earlier were not fixed since SP1. Here are the 2 I mentioned before, again:
- UPDATE_RECORDSET command, when used in the table browser, crashes DAX.
- The left top edge position (the coordinates) of the table browser gets reset when any of the options are changed. I fixed this by specifying 0 instead of -1 for the leftMode and topMode properties of the design. So when you download this tool, the browser will stay in one place, which is nice ;)

Also, 1 new bug I found is for the Russian localization team.
- Changing the view (in the Unmodified version of the browser was causing the full table list to open, prompting the user for a selection of the table). This is caused by a small validation in the SysTableBrowser::main() method. SysSetupFormRun is supposed to be the classId of the calling object. And it is not, because some system wide changes were made to the SysSetupFormRun::construct() method. Anyway, I fixed this small bug as well.

OK. That’s all about the tool and the bugs. I have also been asked by a couple of my readers to write a tutorial on using the SysListPanel class.

That’s exactly what I am going to write about in my next blog entry. After all, there is a new class extending from the SysListPanel class in the DEV_SysTableBrowser project.

DEV_CreateNewProject tool version 2.0.0

Hello, everyone.

I finally got down to moving the latest version of this tool to Dynamics AX 4.0.
Now there is only one project for both versions (3.0 and 4.0)

If you haven't seen this project before, you are welcome to visit the homepage, which contains a description of the features, screenshots, installation instructions and more.

The download link with the new project is:
DEV_CreateNewProject version 2.0.0

Important:
The project was renamed to fit the naming conventions of Dynamics AX. The new name is DEV_CreateNewProject.

(If you want, you can remove the previous version (AxCreateNewProject)).
Leaving them in your application WILL NOT have unwanted effects on your system


Also, I would like to share some knowledge that came upon me today with you.
This might not seem strange to you, but it sure was a surprise for me.
While testing the new version in Dynamics AX 4.0 SP2, I noticed that the form size and position are not saved when I press OK in it.
I dug deeper into system classes and found one extra condition that was added before any data for the form is saved.

The extra condition is:
The AllowUserSetup property on form design must be Restricted or Yes.

So you should keep this in mind when developing forms in the future.

Well, have a great day, all of you.
And do try out the new DEV_CreateNewProject version.

tutorial_Form_Dynalink (a small tutorial on dynalinks)

Today I was asked the following question:

"In dynamics we have a Form Named "Form1" I created a button on it "Button1".
It will manage all the records related to the key in main form. There is dyna link created between the datasources. Only records of the currently selected main Key field will be shown. I need the selected KeyField value on the other form. How can I get it?"


So I wrote a small project to show the different possibilities.
In the project you will find 2 forms, 2 tables and a menuItem connecting the two forms.
3 ways of getting the current dynalink value are shown.

Here is a link to the xpo with the project:
download

Here is a screenshot of the result:



Forgot to give some explanations as well: :)
Basically, all the 3 form methods showing different ways of getting the dynalink value are called from the linkActive method in the second (slave) form.
This method is activated by the system every time a record in the parent form is changed, which allows for dynalinks to work. Great method :)

Fetching Data experiment (CacheLookup property)

Playing around with certain table properties at work, trying to improve performance, I decided to post some results today.

The original job was taken from the Dynamics AX Development training materials (III and IV), which, taking the opportunity, I would like to recommend for reading. Especially I enjoyed chapters dealing with performance issues (a topic that is very interesting to me :))

Well, they write about measuring caching there, which they, actually, shouldn't do, because the job they provided won't work in DAX 4.0 (the counters will be zero) (I guess it was simply copy-pasted from DAX 3.0 training materials - you should never use copy-paste, especially with code :) - trust me, been there many times)

Anyhow, I modified the job a little bit to make my research a little easier.
Here are the results I have received for SalesTable:

Basically, running the job may help you decide, what is the best CacheLookup property value for a given table. 
But first priority is reading about it in tutorials or the Inside Dynamics AX book (basically, it's almost the same information on this topic)

You can do some R&D yourself by downloading the job: download
Have fun!

Also visit the homepage

A bug in validation of methods' access modifiers and class abstract modifier

While testing the new feature of Tabax plugins today, discovered a bug in access modifiers validation.

It is performed only at compile time.
Which means, that if the compiler doesn't know what object the method belogns to, than the validation is skipped.
And you can run protected and private methods from whereever your code is executed.

Here is a simple example: (press cancel in the dialogs, otherwise you will get a RunTime error, because the method pack is not implemented in RunBase)

static void tutorial_AccessModifiersError(Args _args)
{
    Object runBaseObj;
    SysDictClass dictClass;
    ;
    runBaseObj = RunBase::makeObject(classNum(RunBase));
    runBaseObj.setInPrompt(true);
    runBaseObj.promptPrim();
    runBaseObj.setInPrompt(false);

    dictClass = new SysDictClass(classNum(RunBase));
    dictClass.callObject(methodStr(RunBase, promptPrim), dictClass.makeObject());
}

setInPrompt and promptPrim are both private methods. so they should not be allowed to be called this way.

The same thing can be achived by using DictClass.

The funny thing is:
while writing a test example for this post, I stumbled upon another bug - now it's about the abstract modifier of a class.

You all are probably aware that RunBase is an abstract class and cannot be initialized.
Well, in the example I showed this is done using 2 methods again :)

I guess someone should register these with Microsoft.