Microsoft File Transfer Manager Error on 64-Bit Internet Explorer

Most of the materials in PartnerSource / CustomerSource are downloaded using Microsoft File Transfer Manager. Although we are moving towards 64-bit computing, Microsoft is still using this old piece of software which the last release was in 2007. As this software is not compatible with 64-bit of Internet Explorer, you will encounter the below frustrating error:

To resolve this, make sure you are using 32-bit of Internet Explorer. You can find it in C:\Program Files (x86)\Internet Explorer\iexplore.exe.

You can also manually download the FTM here if you are having problem install it from IE.

Dynamics AX Easter Egg

Jacob found an Easter egg in Dynamics AX! Try to create and run the following job:-

static void AXEasterEgg(Args _args)
{;
    info(conPeek(new HeapCheck().createAContainer(), 4));
}

A Danish message will be displayed “Hej Mor, her kommer en buffer”. Google Translate this into “Hi Mom, here comes a buffer”. Interesting...

Original post here from Jacob:- http://gotdax.blogspot.com/2010/11/dynanics-ax-wtf.html

AX 4.0 client slow in startup / logon

On a fresh AX 4 installation (yes, I know it’s still AX 4), we found out that the AX client is slow in startup and it takes about 10 seconds after double-clicking the Dynamics AX icon before the application is fully loaded.

It's really simple to resolve this. Go to IE > Internet Options > Advanced tab > Security node > verify that the "Check for publisher's certificate revocation" checkbox is unchecked.
Once this is done, AX client is loaded almost instantly after double-clicking the icon.

Create Alert using X++ codes

Sometimes Infolog message is not sufficient enough for prompting information to users. It is possible to create alert message using code as an alternative. It is fairly simple to create alert message manually by just inserting a new record in EventTable where all the alert messages are stored. Below is a code snippet for creating alert using code in AX 2009.

static void CreateAlertUsingCode(Args _args)
{
    EventInbox          inbox;
    ;

    inbox.initValue();
    inbox.ShowPopup     = NoYes::Yes;
    inbox.Subject       = "This is the Alert subject";
    inbox.Message       = "This is the Alert message";
    inbox.AlertedFor    = "This alert is just information no links are available";
    inbox.SendEmail     = false;
    inbox.UserId        = curuserid();
    inbox.TypeId        = classnum(EventType);

    inbox.AlertTableId  = tablenum(Address);
    inbox.AlertFieldId  = fieldnum(Address, Name);
    inbox.TypeTrigger   = EventTypeTrigger::FieldChanged;
    inbox.CompanyId     = curext();
    inbox.InboxId       = EventInbox::nextEventId();;
    inbox.AlertCreatedDateTime = DateTimeUtil::getSystemDateTime();
    inbox.insert();
}

Using RunBaseBatchPrintable class

RunBase framework is used when we develop a class to run an operation within Dynamics AX, such as posting a sales order or used in any data manipulation operation. If we need to batch the operation, we will commonly use the RunBaseBatch framework by extending the RunBaseBatch class.

Dialog for a class that extends RunBaseBatch

The RunBaseBatch class does not provide the access to printer such as when running a report. If you need to provide the printer support to allow users to specify the printer options in the operation, you can extend the RunBaseBatchPrintable class instead of RunBasebatch class.

Dialog for a class that extends RunBaseBatchPrintable

When extending the RunBaseBatch class, you need to override the pack() and unpack() methods. If query is used in the operation, you may need to also override the initParmDefault(), queryRun(), and showQueryValues() methods.

When extending the RunBaseBatchPrintable class, in addition to the above methods, you would also need to make the following amendments:-
1) Modify the pack() to serialise the printJobSettings object (inherits from RunBaseBatchPrintable class)

public container pack()
{
    ;
    return [#CurrentVersion,
            #CurrentList,
            queryRun.pack(),
            printJobSettings.packPrintJobSettings()  // Serialise the printJobSettings object
           ];
}

2) Modify the unpack() to deserialise the printJobSettings object

public boolean unpack(container _packedClass)
{
    Version         version = RunBase::getVersion(_packedClass);
    container       packedQuery;
    container       packedPrintJobSettings;
    ;
    switch (version)
    {
        case #CurrentVersion:
            [version, #CurrentList, packedQuery, packedPrintJobSettings] = _packedClass;
            if (packedQuery)
            {
                queryRun = new QueryRun(packedQuery);
            }
            
            // Deserialise the printJobSettings object
            if (isSwappedFromServer)  
            {
                printJobSettings = SysPrintOptions::newPrintJobSettingsOnServer(packedPrintJobSettings);
            }
            else
            {
                printJobSettings = new PrintJobSettings(packedPrintJobSettings);
            }
            break;

        default:
            return false;
    }
    return true;
}

3) To retrieve the user-selected printer settings, you can use the printJobSettings variable directly in the code. For example:-

public void run()
{
    ;
    info(strfmt('Selected printer is %1', printJobSettings.printerPrinterName()));

    // pass the printJobSettings object to run a report based on the selected printer settings
    reportRun = classFactory.reportRunClass(args);
    reportRun.init();
    reportRun.printJobSettings(printJobSettings.packPrintJobSettings());
    reportRun.run();
}

Happy DAXing!!

Unable to submit workflow when non form root data source is used as workflow data source

If your workflow data source is NOT the form root data source, then when you submit the workflow you might encounter the following error:-

Wrong argument types in variable assignment.

The variable assignment error is due to different record is received by the SubmitToWorkflow class rather than the specified workflow record.

Although the WorkflowDatasource property in the form has been specified properly, the SubmitToWorkflow class will always use the form root data source as the workflow data source.
After debugging, I realised that the problem actually lies in the SysWorkflowFormControls class\ initControls() method. The line below

actionBarSubmitButton.dataSource(workflowDatasource.name());

is not working properly to assign the workflowDatasource to the workflow Submit button. Hence the Submit button treats its DataSource property is empty and use the root data source.

I created a quick test to add the SubmitToWorkflow menu item button manually to the form and use the above code to assign the data source. It was still not working.
Then I created another SubmitToWorkflow menu item button, but instead of using code, I specify the data source for the button using AOT Properties window. And this time the workflow was submitted.
So I can confirm that the MenuItemButton.dataSource() method did not do its job properly.

So what’s the workaround? If the DataSource property in MenuItemButton is empty, it will first use the DataSource specified in its parent container (i.e. Group control), and continue search upward till the DataSource specified in the form Design node. If no data source found, it will use the form root/first data source by default.
So to fix the workflow problem, we can use the above behaviour to implicitly assign the data source to the SubmitToWorkflow button. One way to do this is in the SysWorkflowFormControls class\ initControls(), add the below line

actionBarGroup.dataSource(workflowDatasource.name());

to assign the data source to group control that contains the button, which will then inherited by the button.

Unable to find Dynamics AX Web Project template in Visual Studio 2008

Here is some of the teething problems I encountered recently when start developing on Dynamics AX 2009 Enterprise Portal (hope it won't be too late to learn EP!) :-

1) Unable to find Dynamics AX Web Project template in Visual Studio 2008
Although AX Enterprise Portal developers tools has been installed on the MOSS / SharePoint EP server, the Dynamics AX Web Project template still cannot be found in Visual Studio. This is a standard issue with AX 2009 Enterprise Portal developers tools where it only works fine on the account that doing the installation. The AX template is not automatically deployed to other user accounts. The blog post here provides a very details troubleshooting steps: http://mbsturk.blogspot.co.uk/2011/02/missing-ax-ep-web-project-in-visual.html.

2) When opening the Dynamics AX Web Project in Visual Studio, the following error message is displayed
"Unable to connect to Microsoft Dynamics AX. The Dynamics AX Enterprise Portal Tools are not available".
To resolve this issue, verify that the configuration for .NET Business Connector is correct using the AX Client Configuration Utility. One quick way I always use to verify the Business Connector configuration is to export the active configuration to an .axc file and open it directly to see whether an AX Client session could be established successfully.

3) Changes made in Visual Studio not reflected in Enterprise Portal
By default, when you save the changes made in Enterprise Portal, for example, modification to a User Control, it will automatically reflected in Enterprise Portal. If this does not work, you can manually deploy the User Control modification by go to AOT\Web Files\Web Controls, right-click the Web Controls node and choose Deploy. When you save the User Controls changes in Visual Studio, the modification is saved directly to the web controls object in AOT\Web Files\Web Controls. Be sure to restore the modified Web controls object (right-click > select Restore) first before you do the deployment. Visual Studio will use the active Client configuration to determine which layer the changes to be saved in.

Happy EP...ing!