Recurring issue: str2num

There is a general problem with string to numeric conversion in Ax, which seems to resurface now and again.
Last time around when we faced this problem, we were working in the Product Builder modules. We had variables setup with default values like this: 3.200,00 mm
But when Ax loaded the configuration form, the string values were converted to 3 (no decimal value setup - values divided by 1000). Ax had interpreted the thousand separator as the decimal separator. It's easy to test:



test=str2num("3.200,00");



As the values stored for the configurated product models are all converted to string values (table PBATableInstance), there are 2 possible approaches to this problem.

1. Make sure the saved value is stored without the thousand separator. ("3200,00" converts ok to 3.200,00)

2. Make sure the retrieved value is converted back to a numeric value in the right way.



We choose the latter approach. We edited Class PBABuildForm\fillDataSource, where the default values of the product model are set up.



pbaTmpBuildForm.Comma = str2num(strrem(pbaTableInstance.Value,'.'));



(Ax 2009 SP1 - no HF)

Product Builder perfomance tip

With the Product Builder modules from Ax, your users (internal or external) can configure their own products. These products can range from electronic devices (demo company) to basically everything you can imagine.

Loading the form for configuration of the product model can take some time. If you have lots of variables (complex product model), it can take more than 20 seconds. And that's an eternity for some users in this day and age.

So I thought to share this little performance tip with you.

In Ax, setting the properties of a form control can take quite some time. The more variables you have, the more form control properties to set. Think of enabled Yes/No, hidden Yes/No.
Now there's no need to set the property, if it's already set. That's a waste of time. So if a field is already hidden, don't hide it again. If it's enabled, don't enable it again.
But unfortunately, that is exactly what the standard code is doing. But we can change this behaviour: Go the the class PBAFrontEndControl, method SetControlProperties.

Change this part:

dataSource.object(valueTmpBuildForm.activeField()).enabled(enabled);
dataSource.object(valueTmpBuildForm.activeField()).mandatory(mandatory);
dataSource.object(valueTmpBuildForm.activeField()).visible(visible);

into this part:

if(dataSource.object(valueTmpBuildForm.activeField()).enabled()!=enabled)
dataSource.object(valueTmpBuildForm.activeField()).enabled(enabled);
if(dataSource.object(valueTmpBuildForm.activeField()).mandatory()!=mandatory)
dataSource.object(valueTmpBuildForm.activeField()).mandatory(mandatory);
if(dataSource.object(valueTmpBuildForm.activeField()).visible()!=visible)
dataSource.object(valueTmpBuildForm.activeField()).visible(visible);

Similar code can be found in the method with the same name in class PBAFrontEndControlWin.

These small modifications reduced the load time of the form to below 5 seconds for us, where it was first 20 seconds +.

Do you have any performance tips as well? Share them in the comments!

Syntax error in Product Builder module

Recently we came across a small but annoying problem in the product builder modules.
Our product model, perfectly working for quite some time, refused to compile after a minor modification. The error message read:

Compilation error: *** Error: -1, Syntax error.

The error popped up when we compiled a code treenode from the product model. We checked our code, everything looked OK. We didn't make a typing error.

One of the product builder variables we used was named 'DDB'. No problem so far, but when we tried to use this variable in the code segment of our treenode, the error came up. Why?
When used in the code treenode, Ax will declare a variable in the class it creates for your product model, with the same name as used in the product model.
Only, DDB is a reserved name, as this is the name of a function in Ax (it calculates the accelerated depreciation of an asset). Variables in classes cannot be named after built-in functions.

So our solution: rename variable DDB to something else.
Problem solved, something learned.