Creating Edit methods for DS that don’t allow editing in Dynamics ax – Followup

A while ago i made a post on allowing a edit method to work on a disabled datasource .. http://bit.ly/hZMBIW

I found a still better idea from one of the comments, this post is to highlight the comment.

I rather would loop trough all data source fields (FormDataObject) and set them allowEdit=false at initalization time of the form/ds. That’s more confortable for the user, because he sees, that he cannot modify other fields than the edit fields. - Luegisdorf

One suggestion that i would add along to this is creating a SysHelper class for this, in case you find this recurring. You can just pass the record or datasource and the method will disable all the fields.

public class SysDictTable extends DictTable implements SysDictXmlReflectionProvider, SysDictXmlDocumentationProvider
{
    public static void disableDSfields(FormDataSource _fds)
    {
        SysDictTable dictTable;
        int          i;
        ;

        dictTable = new SysDictTable(_fds.table());

        for (i = 1; i <= dictTable.fieldCntWithoutSys(); i++)
        {
            _fds.object(dictTable.fieldCnt2Id(i)).allowEdit(false);
        }
    }
}

Running a .Net reference code in the Server in Dynamics Ax

We have been recently building some .Net solutions for our vertical. I have consolidated my learnings from it and publishing here as a post.

1. Adding a .Net reference can be as easy as just to drop the dll in the client bin folder and then add it. But if you want the code to execute on the server then this wont work. You will have to publish the dll in the server “GAC(Global Assembly Cache)”.  A assembly on the cache executes on the server.  Look here for articles on publishing a dll to the cache (GAC Publishing) and assigning strong name to it (Assigning Strong Key).

2. When you look at for the GACUtil, you will find it in different places in different pc. The general places to look at are,

-> C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin

-> C:\WINDOWS\Microsoft.NET\Framework\

3. Every time you change and build the solution you have to un publish/publish it to the GAC. This can be difficult to do it manually. The easiest way is to add the following lines in your Project -> Properties -> Post-build event command line  in your visual studio project.

//uninstal old version

“gacutil.exe -u $(TargetName)”

//register new version

“gacutil.exe -i $(TargetPath)”

4. Though you run the code on the GAC it is necessary that the dll is added to all the clients just for compilation. It need not be updated as you revise your dll.

5. If the code is present in a server call then it is required to restart the server every time you re publish a new version to the GAC.  What i found better was to test the code by client level execution(Through a job) and once the code is working fine you can move it to the server call.

6. If you are creating a .Net instance in a class and wanted to retain the instance as a global variable then you must declare the variable as CLRObject and not in the actual .Net namespace name(Eg: Microsoft.Dynamics.Csharp). Failing to do so results in a run time marshalling error.

Converting a System.Xml.XmlDocument to XML type in Dynamics ax

When interacting with .Net assemblies mostly  Xml is used to send/receive outputs from the external system. Here is a code snippet that tells how to convert a System.Xml.XmlDocument to a Xml string in Ax which you can use for further processing by classes like XmlDocument…

//CLR Objects
System.Xml.XmlDocument document;
System.Xml.XmlTextWriter textWriter;
System.IO.StringWriter   stringwriter;

//X++ Objects
Xml                      Xml
;

//call to the .Net assembly that returns a XML
document    = processINput(...argument..)

stringWriter = new System.IO.StringWriter();
textWriter   = new System.Xml.XmlTextWriter(stringwriter);

document.writeTO(textWriter);

//Converted to Ax Xml format here
xml        = stringWriter.ToString();

Debugging form controls in Dynamics Ax

The X++ debugger doesn’t get invoked when placing breakpoint(ctrl+f9) in form controls.

There have been quite a few suggestions to work around this like the one mentioned one below

http://axdaily.blogspot.com/2010/04/breakpoint-in-clicked-method.html

http://blogs.msdn.com/x/archive/2009/10/10/condition-breakpoint-workaround.aspx

I have also a suggestion which i think can be slightly better also.

Add a method called bp() to global.

static void bp()

{

;

}

Now when you want to debug  a formcontrol, type bp() there and  place a breakpoint(ctrl+f9) in the global method.

This will invoke the debugger without any issue.

The advantage here is

>> You need not bother about “breakpoint”  in the code that is shipped.

>> With hardcoded breakpoints you cannot stop them when you want the code to execute, but with this bp() method you can easily remove it  as it is just (ctrl+f9) based.

>> At the end typing bp() is easy then typing breakpoint

Setting up Form size during runtime in Dynamics Ax

Sometime we change  or construct a form at  runtime. In those situation we end up modifying/setting the width and height at run time itself.

there is one thing you need to keep in mind if you are doing that.

Don’t use the following way to set the size of the controls in forms

tabcontrol.width(FormWidth::ColumnWidth);
tabcontrol.height(FormHeight::ColumnHeight);

tabcontrol.width(100);
tabcontrol.height(200);

then nothing happens for the Form. The form size is actually set to zero.

Instead you must do it the following way….

For Auto/ColumnWidth, height properties, set it like this

  tabcontrol.widthMode(FormWidth::ColumnWidth);
  tabcontrol.heightMode(FormHeight::ColumnHeight);

For setting manual values set it like this

  tabcontrol.widthValue(100)
  tabcontrol.heightValue(200);

I’m not sure for what reason it is done like this