Tuesday, November 20, 2007
The Inside Microsoft Dynamics AX 4.0 book will very soon be available in Russian.
I was the one helping with the translation.
I am now finished with all 18 chapters with just some minor corrections left to other parts of the book.
So I will try to get back to posting about AX very soon.
Next week, on Tuesday (November 27th) Moscow will be hosting an annual Microsoft Technical Event.
You can read more about it on http://platforma2008.ru/ (Russian language only)
The new book will be presented there, so make sure and visit if you can.
I was replying to one of the posts on the community and noticed, that now I have a bronze medal near my name.
Here is what it means:
(it means I had 51 replies marked as Answers)
Saturday, October 20, 2007
- In the init() method of the form, you need to initialize the listPanel class, specifying, that it is this form you want the list panel to be on, the group that the list panel is going to be in on the form, and any other relevant parameters (for example, when using SysListPanelSet, you usually pass the current state of the values (inSet) as well.
- Most convenient way to accomplish this is by creating a static method with the needed list of parameters, and call this method from the init() method of the form. Usually, this method is named newForm.
- The SysListPanel class contains a lot of parm* methods, that you can use to modify the behavior of the list panel. The SysListPanelSet adds another method to that list, allowing to set the current set of selected values (parmInSet). You can see how these methods are used in Classes\SysListPanelSet_Fields_TableBrowser\newForm() method.
- After basic initialization you have to call the build method. The build method of SysListPanel class is responsible for actually adding all the needed controls to the specified form. Depending on the parameters that you set before calling this method, the list panel will/won’t add the “Add All”/”Remove All” buttons, the “Up” and “Down” buttons, will set the needed number of columns shown in the panels, etc. You can override any of the methods, adding additional functionality (see \Classes\SysListPanelSet_TableBrowser \build() method) or even completely rewrite the code of the basic method (this is not recommended, of course). Notice, that the build method should be called BEFORE super() in the form’s init() method, because FormBuild*Control classes are used to add controls to the form.
- After build method is executed, all FormBuild*Controls are initialized. You need to call the init method then, so that all Form*Control variables are initialized. This method should be called AFTER the super() call in the form init method, as Form*Controls don’t exist until super() is called.
- The last thing you have to do is call the fill method of your new class, so that the list panel is filled with needed data. Let’s talk about this method in a little more detail below.
The Classes\SysListPanel\fill() method, basically, consists of 4 parts:
- getData method is called. This is the method that gathers the data for the left and right part of the list panel. This is an abstract method, and it has to be implemented in the extending class. It returns a container with all the information for the list panel. It is different from class to class and depends on the data being shown in the list panel.
- Both parts of the list panel are cleared and list panel columns are created (the first time).
- fillView method is called for both parts of the list panel. These methods use the data generated in step 1.
- Buttons are enabled depending on the data in both list panel parts. For example, if there are no items selected (left part of the list panel), than the "Remove" and "RemoveAll" buttons are disabled.
The rest of the methods on SysListPanel class are for handling events that occur from user interaction.
The class is the handler of these events in most cases, controlMethodOverloadObject method is used to specify that when the list panel is built.
I guess, the only two methods left that are worth mentioning are the abstract methods addData and removeData. Both of these have to be implemented in the child class, providing the logic for adding and removing items from the left part of the list panel. For example, for SysListPanelSet class the implementation is very simple, just adding or removing the item from the inSet object. For classes extending directly from SysListPanel these methods are where the main logic is located, adding or removing records from the database. In most cases, these methods simply call a server method that does all the needed actions (Remember the rule of thumb – place database logic as close to the database layer as possible).
That is pretty much all you need to know to use and create list panels in Dynamics AX.
Of course, this is not a full description, and much can be added to the information posted here.
If you have any additions, corrections or questions, feel free to post them as comments.
Friday, September 14, 2007
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:
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.
Monday, September 03, 2007
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
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.
Wednesday, August 22, 2007
"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:
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 :)
Monday, July 16, 2007
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
Also visit the homepage
Wednesday, June 27, 2007
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)
runBaseObj = RunBase::makeObject(classNum(RunBase));
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.
AndyD has developed a class that allows me to do this now.
The project containing the class with the images is "shipped" separately. Depending on where you want to see images in your popups menues or not, you will be able to import it separately if you do.
You can use the following links to download the projects (version 0.1.1) and the MenuImages class.
RecentProjects v. 0.1.1 -download
RecentWindows v. 0.1.1 - download
Class MenuImages - download
Alternatively you can download them from their homepages on Axaptapedia.
RecentProject - homepage
RecentWindows - homepage
Tuesday, June 26, 2007
A short description of what the tool can do for you: :)
Basically, it just changes the backcolor of your DAX 3.0 (it does not work for DAX 4.0) installation.
You can choose a simple custom color you would like to use, or select an image from your hard drive to use as the background image.
you can select a couple of settings as well (ALL the settings are accessed by pressing Alt + S in DAX after launching the AxPaint form) - like stretching the image or using a 'transparent' background, showing your desktop (you have to set the image path to a specific location for that).
Nothing much, you'd say. But it sure is fun to work in DAX when a nice picture is seen in the background. :)
- Unzip the archived files.
- Place the .bat and .ocx files somewhere where you won't delete them accidently.
- Run the .bat file, which will register the .ocx
- Import the project into Dynamics AX - the project contains one form AxPaint.
- Run the form. It will automatically hide from view. Press Alt + S to run setup.
- The image path is setup to C:\Documents and Settings\%username%\Local Settings\Application Data\Microsoft\Wallpaper1.bmp - this is the path to the current wallpaper in Win XP (without active desktop)
- Show desktop (like Delphi) option is set in the setup dialog.
- In the startupPost method of the Info class the following lines are added:
- An external application is used to change the wallpaper on system startup. So every day I have a different look in my DAX :)
Custom code for the info.startupPost method:
if (curUserId() == 'ikash')
Link to the external WallChanger application:
Monday, June 25, 2007
Anyway, what I needed to do was:
- Override the basic lookup for a specific control on the dialog.
- Prevent user interaction with other forms until the dialog is closed.
- Make some of the controls in the dialog mandatory.
But the code was very highly customized, so it would be a hard job.
So I decided to go another way, using what I have on hand, and that is the Dialog class.
For that, I needed a couple of modifications to the Dialog class, as it does not allow any of the 3 features I neded.
But what any developer should clearly understand when using dialogs is - this is just another form. Simple as that - Dialog is just another AOT form. What this means is that with a dialog we can do all the things we can do with a form.
Also, which is very nice and I thank DAX Developers for that, RunBase framework uses DialogRunBase class for showing forms, and this class is extending from class Dialog, so changes made to Dialog will also be available in RunBase framework.
Here is a small explanation of what has been modified:
- Added a class Dialog variable showModal, which controls the modal state of the used dialog.
- Added a parm method to set the value of the showModal variable. So, basically, to make a modal dialog you simply have to call this method passing true as the parameter.
- Added a method SetFormModal, which actually does all the enabling/disabling of windows (DAX 3.0 only, as DAX 4.0 already has built-in modal forms)
- Modified runOnClient() method to allow server dialogs to run modal as well
- Modified wait() method, which calls SetFormModal method (DAX 3.0 only)
- AddField and AddFieldd modified to allow specifying a specific name for a control.
- DialogField class was modified to allow setting the mandatory property (mandatory(), unpack() methods) and specifying a specific name for a control (new and fieldname methods)
- Class\Dialog - only modified methods
- Class\DialogField - only modified methods
DAX 3.0 Download link (was created in DAX 3.0 SP5 KR2) - DOWNLOAD
DAX 4.0 Download link (was created in DAX 4.0 SP1 EE) - DOWNLOAD
After importing the project do not forget to compile forward the Dialog class and to restart the DAX client.
Certain Issues you should know about:
- InfoActions, if present, will allow to access forms, if the infolog window with them was opened before the modal dialog was called.
- Mandatory property starts working only after a value is entered into the control. What this means is that if you simply press OK right after the dialog is opened, you won't receive an error (regular forms works this way too)
The modification allowing to specify a specific name for a DialogField was originally posted on the Russian Axapta forum
Tuesday, May 15, 2007
I found this to be very convenient, that's why I wanted to lay my hands on the SysExportDialog form and add this feature in there as well.
And that's exactly what I did today.
This turned out to be a task a little harder than I'd hoped, because there are special methods on the TreeNode class that allow to see the type of the object. Those methods are not present in DAX 3.0 yet, so I had to write something similar (probably on a more primitive way, as this is the only place the code will be used - unlike the DAX 40 modifications which are now available everywhere the Treenode Class is used)
Also, I "fixed" a small issue that was present in DAX 4.0 with this: exporting an entire node of objects (e.g, Forms) resulted in the following name of the file : "_Forms.xp".
Anyway, here is the xpo file -- notice the neat name of the file ;). -- download Form_SysExportDialog.xpo
The file contains the SysExportDialog form only.
The original form was taken from DAX 3.0 SP5 KR2.
Hope you like it as much as I do ;)
Monday, May 14, 2007
Before installing any of the plugins, you need to install Tabax 0.3 or later and the DEV_TabaxSDK
Use the following link to download the latest version of Tabax and SDK: http://axaptapedia.com/Tabax
DEV_TabaxPlugin_OpenInAOT – download
(homepage - http://www.axaptapedia.com/DEV_TabaxPlugin_OpenInAOT)
This is a very simple plugin, based on a tool I made a while ago (you can download the original EditorScript at http://www.axaptapedia.com/Editor_scripts_OpenInAOT).
This tool is available only to developers (SysDevelopment security key).
Installation instructions are very simple: just import the project and refresh the AOD (this is specifically needed for the rich AX4 client)
Now you can open AOT objects just by typing their name in the Tabax form edit box (prefixed with ‘go’).
Here are a couple of examples:
- “go InventTable” will open the Tables\InventTable node.
- “go InventDimDevelop” will open the Macros\InventDimDevelop, etc.
DEV_TabaxPlugin_RecentProjects - download
This plugin, when started (which happens automatically on startup of Tabax), adds a button on the Tabax toolbar. (it resembles an ‘Undo’ button).
This plugin keeps track of projects you use during the day, providing for a simple and fast way to open one of them.
This tool is available to developers only. If you do not have developer rights, the button will not be added to the toolbar.
Here is a list of what will happed when the button on the toolbar is pressed:
- A context menu is rolled down showing the list of projects recently used. (maximum 15 projects are shown, but the number can be changed in the plugin ClassDeclaration method)
- The first 10 entries are assigned hotkeys (1 to 10 (0) respectively).
- If Ctrl key is pressed, the last closed project is opened (the selection form is skipped).
- If Shift key is pressed, the selection form is opened, providing more functionality than the context menu.
- In the context menu of the selection form you can find menu Items that clear the contents of the recent projects list or control startup project settings.
- You can cancel the form by pressing Esc or the CloseDialog button in the top right corner
To users using Sidax this button will be very familiar, as it mostly copies the functionality available on the RecentProjects tab there.
DEV_TabaxPlugin_RecentWindows - download
This plugin, when started (which happens automatically on startup of Tabax), adds a button on the Tabax toolbar. (it resembles a green ‘Recycle Bin’).
This plugin keeps track of windows you use during the day, providing for a simple and fast way to open one of them again.
This includes editor windows, AOT object windows and regular Axapta forms (this does not include forms opened from other forms).
This tool is available to both dev and non-developers. If you do not have developer rights, the AOT and editor windows are not kept track of and the recent windows list is used solely for DAX forms.
The nice part of this is the specific record you last used is remembered as well, so you can reopen a form and start working with the record right away. (AxPath is used for this)
The functionality of the toolbar button is similar to DEV_TabaxPlugin_RecentProjects.
That's it. Come back for more :)
Monday, May 07, 2007
More than 2 years have passed since the day I took my last certification exam.
Today I passed the AX 40-508 (DAX 4.0 Development Introduction) exam, so now I am a Microsoft Certified Business Management Solutions Specialist in Dynamics AX.
Don't you love it how certification titles get longer and longer every time their name is changed? :)
As for the exam itself, I should say that it was a little bit of a disappointment. At least, I was expecting more from it. Basically, it was the same DAX 3.0 Development Exam, with only 5 or so questions added for Dynamics AX 4.0. Of course, it's a DEV INTRODUCTION exam, so I guess I shouldn't be expecting much from it.
Anyway, I will be anxiously waiting for the MorphX Solution Developer Exam. Hope they will actually try to write some new questions for this one. ;)
Wednesday, April 25, 2007
Specifically, the following is covered in this tutorial:
- A short description of the system class BOX
- Creating a form from a class (using classFactory), launching different form methods, waiting for the form to be closed by the user and returning the selection
- Differences in implementation between DAX 3.0 and DAX 4.0
You can download the project from the following link:
Classes\Box is a simple class used throughout the DAX application. It provides an interface for showing a standard dialog with a number of selection options and a short message. This is very useful, especially during development, because it provides a fast way to show some kind of text information to the user.
The class contains a number of methods that can be extended with new ones (as shown below). All the methods are static and have the keyword client in the declaration, which forces the code in them to be executed on the client side.
The most commonly used methods of this class are:
- box::info("message"); (for debugging purposes),
- box::warning("message"); (for showing a warning message that the user won't miss)
- box::yesNo("Message", dialogButton::Yes"). (for allowing the user to select the course of action for the underlying business logic)
All the methods mentioned above are simply creating an object of class DialogBox, which is system and doesn't allow to see its implementation. This class is therefore not covered in this tutorial.
The rest of the methods is rarely found in the application code, and is suited for specific situations where you need to provide the user with the option of choosing from more options. (for example, when imporing a project, you see a dialog created by the method box::yesAllNoAllCancel();
The implementation of these methods is very much alike: (example mentioned above)client static DialogButton yesAllNoAllCancel(str _text, //message
DialogButton _defaultButton, //default dialog button
str _title = "@SYS11132") //dialogTitle
args = new Args();
args.name(formStr(SysBoxForm)); //form SysBoxForm is used to show the message
formRun = classFactory.formRunClass(args); //creating a FormRun object
formRun.init(); //calling init of the form
formRun.setTitle(_title); //setting title of the form (caption)
formRun.setText(_text); //setting message
formRun.setType(DialogBoxType::YESTOALLNOTOALLBOX); //setting the type of the form
formRun.setDefaultButton(_defaultButton); //setting the default button
formRun.run(); //calling run of the form
formRun.wait(); //waiting for user action
return formRun.dialogButton(); //returing the user selection
The example creates 2 objects that are needed to run a form from code:
Args args - not discusses here (used to specify the name of the form that is being created)
Object formRun - that is the actual object of the form being created.
You might have noticed that it is of type Object and not FormRun. (using the base type)
This is done on purpose, as there is no compile-time validationg of methods actually existing on the form. If the method doesn't exist, you will receive a runtime error, which is not really appropriate in a live environment. So in your code you should chech that the methods being called do actullay exist. (Global method formHasMethod can be used for this purpose)
After the form is initialized and all the setMethods() are called, the Run() method is called. This method executes the form and shows it on the screen.
After the Run Method we see a call to formRun.wait(); This method notifies the RunTime that the code execution should stop here and wait until the form is closed. (if this method is used on a form to call a child form, the parent form cannot be closed before the child form)
[Note: The alternative method here is the detach method (behavior of MenuItem calls)]
After the user closes the form, the dialogButton method on the form is called to return the selected value. [Note: Notice, that the methods on the form are still accessible, even though the form is already closed by the user. This happens because the formRun object is not yet destroyed]
I added another method to the box class - yesNoWaitForm. It opens a form that looks kinda cooler than the standard forms, because it has the option of autoclosing after a set period of time. Well, everyone can find his own uses for this form. The form name is Dev_SysBoxForm and it is an almost complete duplicate of the system SysBoxForm form. The only big difference is that this form is set modal, and that the text of the default button is appended with the remaining amount of time before the form is autoclosed. [Note: SetTimeOut method is used, which is not covered in this tutorial]
There were differences in implementation (compared to the sytem form SysBoxForm). The main are listed below:
- DAX 4.0 already has a modal window option (wait(TRUE)); So custom methos are removed from the form
- DAX 4.0 has the minimize and maximize system buttons visible on the dialog form, and they had to be turned of on the form design.
- In DAX 4.0 The return value of method formRunObj.dialogButton() was not automatically converted to the correct type. So an extra variable way added to the method to convert the result to a specific type of DialogButton. [Note: I think that this is a bug]
- The font size of the html (message) was increased by 1, because the default font size seems too small to read.
The project also includes a job that contains a couple of examples of using the new method. Enjoy!
Thursday, April 19, 2007
Today I downloaded a very nice project for DAX 4.0 from www.axaptapedia.com
It inserts a number of lines of code into the SysSetupFormRun class, method task, providing a hotkey to access usefull information about any control on a form.
The hotkey is 'Ctrl + Q'.
Here is a screenshot of the result:
I moved the project to DAX 3.0, because I liked it a lot. Previously I used the Tabax button, which is convenient too, but does not provide as much info as posted above.
Here is the download link for the project:
Also, my friend AndyD created a very good project for DAX 4.0
Description: After moving to DAX 4.0 a lot of users complained about the 'Ctrl + F' key combination. Now, instead of a 'Filter by Field' operation it opens a 'Global Search' window, which is uneasy to use so far.
Anyway, AndyD created a small dll file that replaces the 'Ctrl + K' key combination with the 'Ctrl + F' key combination, leaving the 'Global Serach' intact, but, at the same time, providing a well known interface for DAX users.
Thanks again, AndyD. :)
All you have to do is download the dll file (donwload link) and add the following lines of code into the Info class:
InteropPermission perm = new InteropPermission(InteropKind::DllInterop);
// DEV_AxFindReplacement Replace Keys F and K when used with the Ctrl key 19.04.2007 IKASH -->
dllAxFind = new dll(@"D:\Install\Dynamics AX\Dynamics AX 4.0 SP1 EE\axfind.dll");
// DEV_AxFindReplacement Replace Keys F and K when used with the Ctrl key 19.04.2007 IKASH <--
Notice, that the path to the DLL file, specified above, will be different - insert the correct path to the DLL file instead.
Reboot the DAX client. And you are done.
Friday, April 13, 2007
Please visit http://www.lulu.com/content/723888 to order the book now (Paperback or download versions available)
Also, there is a special offer for people living in Kiev, Ukraine and Moscow, Russia.
You can contact
- Ivan Kashperuk to order a paperback copy of the book to be delivered to Kiev.
- Mihail Rzevsky to order a paperback copy of the book to be delived to Moscow.
Also, you should understand, that this is simply about helping people to buy the book, it is not a commersial affair, as translators won't get any or very low revenues from this.
P.S. lulu.com also provides a review of the book and a free sample chapter preview.
P.P.S. You might have to wait for the delivery for some time, as orders are processed only after a certian quantity is collected.
Saturday, April 07, 2007
Today I provide you with another tool for Dynamics AX developers. It is a modified version of the SysTableBrowser (See picture 1).
- The table browser does not change its position when a different setup is selected. (Unlike standard system behavior in DAX 4.0)
- The AutoReport option was extended, and now you are able to select any of the table field groups (See Credits).
- Another selection option was added, providing the means to select any of the table fields to be shown in the grid. To do this, just press the ‘Select Fields’ button and select the fields you want displayed (See picture 2).
- Added a list of presets for the SQL window. (SELECT, UPDATE, DELETE). The list can be easily extended to include other presets you often use.
- Extra logic was added to the ExecuteSQL button, which executes the SQL string that the user has put into the SQL window. If it is a simple select (for example, generated by the SELECT preset), the ds query is executed instead of the sql string. This will bring back the sorting and filtering options that disappear after using the sql string query.
- Added the ability to sort columns by name or by id. In some cases (when, for example, you cannot find a specific field) it really helps out! (See picture 3)
Possible future improvements:
- Add display methods of the selected table to the list of fields in the select dialog.
The modification was inspired by a similar one performed by Nicolai Hillstrom for Dynamics AX 3.0. I moved it to DAX 4.0 and added some extra features I considered useful. One of them is implemented here (even thought I wasn’t able to download it and see how it is programmed).
Wednesday, March 28, 2007
In the process, I decided to take note of what I like in the new release, and also write down any bugs I find so that someone can send them over to Microsoft to be fixed.
(this is compared to Dynamics AX 3.0 SP3, but also tried out in Dynamics AX SP5 KR2)
Here is the small list I got so far:
- When pressing Enter to go to the next line in the X++ Code Editor window, the cursor is automatically positioned on the same column as the previous line. This was also present in DAX 3.0, but only after 2 lines are positioned in the same way (when adding a lot of conditions in the where clause, for example). But, there is a small 'bug' here. If you put the cursor at the end of a line of code, press Enter, the cursor will automatically get positioned under the line. Press Tab to indent one time. And then hit Enter again. The cursor is supposed to be directly under the line in the same column. But instead, it is position in the first column of the next line.
- When exporting any object to an .xpo file, the file gets a friendlier name, prefixed with the type of object that is being exported. For example, if you export the InventTable form, the file name would be 'Form_InventTable.xpo', which is pretty cool and helps to find the needed xpo file easier later.
- The Hot Keys for the Dynamics Debugger have been changed from F7, F8 to F10, F11. This is very inconvenient at first. And not just because you have to press different keys now. But because the F7 key actions were moved to F11, and F8 - to F10. By now I was used that the left key would take me deaper into the implementation. now it's vise versa.
And here is the bug list (some of them might have been fixed by now, or moved to the Known Issues, but I am unaware of this, sorry):
- The multiline comments are not colored correctly. The first slash is black, if the multiline comment spreads over more that one line. The rest of the comment is green, as it should be.
- In the table browser form, the UPDATE_RECORDSET command crashes Dynamics AX.
- After compiling a project, some of the tables in it are marked as DIRTY (red line near the name). This does not happen to all of the tables, but to those that it does, it happens all the time. Walkthrough: select a table in the AOT, compile it. (no changed done to the table). Then, compile the project. The previously selected table is marked in red. also, one of the tables in my project is always marked dirty after compilation.
That's all I have stumbled upon so far. And I am pretty sure more is to come. ;)
Friday, March 23, 2007
So far there is only one location you can purchase it from (only paperback edition):
I am still trying to find a Print on Demand service based in Moscow or Kiev, but no luck so far.
If you have any questions or suggestions regarding the book, feel free to e-mail me or post a comment here.
Here is information on delivery costs (for Kiev, Ukraine):
economy - $10.81
standart - $17.50
express - $26.09
Friday, March 16, 2007
Updated the project for creating projects ;) to version 1.3.2
- When a project is updated, or "duplicated", the project settings are not stored, so that the node selections and project name & prefix are as they were last time the project was actually created. Most of the developers have a fixed project prefix and name, and layout. But sometimes, rarely we have to modify the layout. Then, when we need to create another project, we have to reset the settings to the stardard layout we used. Well, now we do not have to do it outselves.
- The "Copy Objects" button is always visible now, only disabled when not needed - this is done to promote the using of this feature, as I gather that most devs don't even know that it exists. :)
- MenuItemButton text has been modified to show the behaviour when pressing Ctrl (updating a project)
- Another project group node was added to the dialog - More... This group node contains the rest of the Data Dictionary Nodes. By default, it is collapsed, because rarely used. The rest of the AOT nodes (SystemDocumentation nodes) will not be included.
Also, the tutorial on MultiSelect options has been updated slightly, giving the opportunity to test Set(Types::Record) and InventTable.setTmp(). See homepage for details.
Tuesday, March 06, 2007
After posting the first AX tutorial about Multiple Selection options in Dynamics AX we had a very interesting discussion about what's best to use in DAX at www.axForum.info
After this discussion, I decided to dig into the issue some more and see for myself, what is the best choice here.
So I modified the previous project a little bit: (you can download it here)
- Added a Server-Based class that does all the processing of selected lines
- Added a temporary table, tmpInventTable, consisting only of one field, ItemId.
- Added a job - an approximate way to determine the memory wastes for filling different types of objects.
- Added 2 tab pages to the form, so the form now allows five tipes of processing:
- Using a Set
- Using a Set (the query uses a JOIN)
- Using a Temporary Table
- Using a Temporary Table (the query uses a JOIN)
- Using standard DAX way with multiselecting records
The good thing is that now everyone can try out the different options and choose what is most appropriate for his specific needs.
After this, I also did a test run on a 3-tier installation and on a 2-tier installation.
Here are the Memory test results: (the first is in 2-tier, the second - in 3-tier configuration)
Here are the Processing test results: (the first is in 2-tier, the second - in 3-tier configuration)
The results of my tests can also be found at the homepage of this tutorial.
As you can see from the results, the 3-tier environment provides more balanced results. And in 2-tier I got 25 to 60!!! times increase on Processing tests when not using joins. I would love to know what your resuls will be.
Filling in data is also slightly slower when using Temporary Tables, but the difference is not that great, especially if you take into consideration the amount of records inserted into it (up to 100 000)
You comments and suggestions are very welcome.
Monday, March 05, 2007
This should be used with extreme caution and only by experienced developers (people, who know what they are doing)
Get the tool at axaptapedia
Someone may ask - why would I need to prevent syncronization? Isn't it what should be done at all times?
And the answer is, of course, YES.
But just stop for a minute and remember the amount of time you have to wait till syncronization is over after adding just a single EDT or tablefield. Or, what most people do, Break the operation and (if you managed to actually break it) do it for every field being added. Or, which is even better, export the project, modify the xpo file and then import it back into DAX. :) A nice way, no doubt.
Well, here is a small and simple solution. When syncronization is about to begin, a dialog will popup asking if it should continue. If not, the syncronization will not be performed.
Actually, you can specify the exact way the system should behave through your user settings. The 2 checkboxes are added to the SysUserInfo table: one specifies if the syncronization should be performed, the second - if the user should be prompted with a dialog.
My settings are: 1 - not checked (means should go on with Sync), 2 - checked (means the prompt dialog is going to pop up)
This thing really saves a lot of time.
Wednesday, February 21, 2007
I was going through the Jobs node in my application recently, and stumbeled upon a lot of good examples of different programming technics. I thought it would be nice to share what I have :)
So with this post I will start a series of tutorials on Axapta development.
Today's post is about selecting multiple records on a form (using checkboxes instead of standard Axapta method)
The homepage for this tutorial in on Axaptapedia
It is a simple tutorial form based on InventTable datasource. You can select multiple lines and process the lines by pressing Process lines button.
Here is a short list of what is covered in the tutorial besides the main point of processing selected lines:
- Using edit methods in a grid of a form.
- Using Foundation class Set to collect selected lines.
- Using SetIterator class to go through elements of a Set object.
Preview of the form
Thursday, February 15, 2007
Here is another tool for Dynamics AX developers.
All it does is populates the Windows Clipboard with the lines that you can paste into your code, so you won't have to retype the same code many times.
Download the tool here
Features (You can ... ):
- Insert a variable declaration before using the name; You will have to move the declaration where it belongs if pasting in the middle of a method.
- Insert a call to clear() method of a table variable in order to clear its contents. This is useful, for example, when doing inserts in a loop.
- Specify a different variable name than the one by default (tableName). If the variable is unacceptable, the image on the right will point out the mistake.
- Choose which fields to copy into the clipboard. There are 2 presets so far. The list will be extended in future releases.
- Insert a call to insert() or update() after the lines with field values assignment.
The tool can be integrated into the system in a couple of ways:
- Insert the menuItem AxCopyTableFieldListToClipboard into the SysContextMenu menu. The text "Copy Table FieldList" will be automatically added to the context menu on AOT objects. In order to sort this out and show the text only for tables, you have to modify the method verifyItem of the SysContextMenu class. Paste the following code into the appropriate section (after case MenuItemType::Action:)
//--> AxCopyTableFieldListToClipboard_ikash date=2007-02-11 txt='Show in menu only for tables'
if (this.selectionCount() != 1 firstNode.AOTIsOld())
if (!docNode && firstNode.sysNodeType() == 204)
- Insert the menu Item into the GlobalToolsMenu or the DevelopmentTools menu. Then select a table in the AOT and run the menu.
- You can add the bmp image attached to the project into the plugs folder of Tabax and you will automatically be able to launch the tool from the Tabax toolbar.
- You can select a table name in the editor and call the tool from the editor scripts. In order to insert the tool into the editor scripts create a method with the following code in the EditorScripts class.
void AOT_Copy_TableFieldList(Editor e)
Args args = new Args();
new MenuFunction(menuItemActionStr(AxCopyTableFieldListToClipboard), MenuItemType::Action).run(args);
Also (especially DAX 4.0 users), take a look at the link to Casper Kamal's post. He describes similar functionality already included in the 4.0 release.
Hey, great to know MS developers and I are thinking the same thoughts ;)
Anyway, here is the link:
- aidsua - for a hint on the match function
- AndyD - ListView setColumnWidth help and WinApi stuff
Thursday, February 08, 2007
Moreover, I updated the script that finds the selected object in the AOT with the new code fixed by AndyD - now the selected line is parsed correctly even if selected by keyboard.
You can download it from it's homepage only, as this editor is not well suited for copy/pasting of code. :)
I have also upgraded the tool for creating new projects to version 1.3.1
The new feature are:
Fixed a small bug I stumbled upon recently: If you temporarily turn off the project prefix that contains a long name, and enter a long name for the project, the validation fails telling that the project name is too long - the CheckBox value is not analyzed.
Now you can update an existing project adding new project nodes to it. Just select the project you want to update and hold the Ctrl key when calling the AxCreateNewProject tool. This will automatically initialize the Settings Tree with the project group nodes found in the selected project. Also, the warning confirmation message won't be shown when you press the OK button and the existence of a project with the same name is not considered an error in the image window.
Moreover, you can now selectively duplicate the objects of an existing project together with the project group nodes. In order to do this select an existing project for update and simply input a new name for the project. You will notice that a button Copy Objects will appear in the bottom left corner of the dialog window. Pressing this button will add the objects found in the selected project into the Settings Tree and will be copied into the new project as well. You will be able to deselect some of the objects (see Known Issues) if you do not need to carry them over to the new project.
You can download the new version HERE or from the Homepage
I haven't posted in a while. Work, work...
Well, meanwhile, I made some new handy tool for Axapta developers.
Finds the declaration of the selected variable and opens the editor on the line with the declaration
Searches the current method first. If the declaration is not found, goes to the root of the object and looks in the classDeclaration method. If still not found, continues on with the parent of the class.
In order to use the tool simply import the project
and post the following code as a new method of the EditorScripts class:
void AOT_goToDeclaration(Editor e)
goToDeclEngine = new AxGoToDeclaration(e);
- ParserClass does not parse the constructor (new) method. So variable declarations cannot be found from this method.
- Does not find variables this, element, etc.
- Does not find objects with AutoDeclaration set to Yes on forms, nor the datasources
What is planned for upgrade:
- Open AOT objects when this or element is selected (table, class, form, etc)
- Open AOT objects with the property sheet for objects with AutoDeclaration = Yes
- Include global classes into the search
- AndyD - for the timer AOT edit code and the selectedLine method modifications
- MaxBelugin - for ParserClass description
FeedbackIf you have any comments or suggestions, please feel free to contact me.