Implement WorkSheet.Copy in \Classes\SysExcelWorksheet

This is how the method should be implemented:

public void copy(SysExcelWorksheet _before = null, SysExcelWorksheet _after = null)
{
    anytype before, after;
    ;

    if (_before)
        before = _before.comObject();
    else
        before = COMArgument::NoValue;

    if (_after)
        after = _after.comObject();
    else
        after = COMArgument::NoValue;

    worksheet.copy(before, after);
}

Getting "Runas" back into your life

When testing different uses scenarios on AX, I usually use "Run as..." to open a client as another user. That option is removed from a lot of programs in Windows 2008 (and Vista) and typically won't work on AX configuration files (axc).

I (or actually Google) found this tip on "Norm's PerformancePoint Server blog", on how to get RunAs back:
http://blogs.msdn.com/normbi/archive/2008/04/26/adding-runas-back-into-vista-and-windows-2008.aspx

Print images directly to a printer with ShellExecute (in XP)

If you need to write code in AX to print an image file directly to a printer, your first thought might be to call shellExecute like this:

winapi::shellExecute(filename.jpg, '', '', 'print');

This would be fine with other types of files, but in XP image files will be printed via the Photo Printing Wizard, so in this case you simply don't get the file printed.

If you open Tools / Folder Options from an Explorer, go to the tab page File Types and find the type of image you want to print, you can click Advanced button to see that the operating system does when you right click on a file of that type and select print. If available the information will be under "printto". For TIF images on my box, I can see that this is what it will call:

rundll32.exe C:\WINDOWS\system32\shimgvw.dll,ImageView_PrintTo /pt "%1" "%2" "%3" "%4"

So in reality this is what you have to call through shellExecute.

Here is a sample job for that:

static void TestPrint(Args _args)
{
    ;
    winapi::shellExecute(@'C:\WINDOWS\System32\rundll32.exe', @'C:\WINDOWS\System32\shimgvw.dll,ImageView_PrintTo /pt "C:\MYIMAGEFILE.TIF" "\\PRINTSERVER\PRINTERNAME" "%3" "%4"');
}

X++ based Web User Interface is discontinued in the next version of Microsoft Dynamics AX Enterprise Portal

Hardly a big surprise....

http://blogs.msdn.com/solutions/archive/2009/08/20/x-based-web-user-interface-is-discontinued-in-the-next-version-of-microsoft-dynamics-ax-enterprise-portal.aspx

Use keyboard lookup in Product Builder enumerated fields

In the standard product builder you cannot use Alt-Arrow Down to use the lookup on your enumerated fields. This has been an error since the release in version 3.0 and it doesn't seem like it will be fixed before AX 6.0. So I have looked into how this can be accomplished without too much messing around with the product builder.

The reason that you cannot use the lookup from the keyboard is that the AX kernel reasonably enough decides that there is no point in activating the lookup. The key problem is simply to make the kernel accept that there is a point in activating the lookup.

All the enumerated field is based on the table field \Data Dictionary\Tables\PBATmpBuildForm\Fields\tmpString which again is based on the extended data type PBATmpString. The extended data type has no relations on it, and that's the simple reason that the kernel won't activate the lookup.

So to make the kernel activate the lookup I have created a new table, PBASupportEnumLookup, which the extended data type now has a relation to.

Now the kernel will activate the lookup, but it will also try to validate the entered enum values against this table. So I must insert all enum values to the new PBASupportEnumLookup table. I do that in validateField of PBATmpBuildForm before validating the field entry.

The validation part would not be needed if I could get this to work with table relations, because on a table relation I can set the Validate property to no. But unfortunately, a table relation is not enough to make the kernel run the lookup.

Everything else is handled by the product builder code, which already works fine if users in standard use the mouse to open the lookup....

Adding the enum entries to a new table is obviously not the most desirable solution, but it works and it works with minimal footprint in the standard code base. And the users are happy!

Found a Sleep statement in AX 2009 released code

It's awfully nice of the developer to leave the users some time to be able to read progress in the progressbar ;-)

Document management on Return Order may apply documents to wrong record

The following bug applies to AX 2009 application build number 5.0.1500.809 and earlier.

When you attach a document or note through document management to a return order line, the document or note might be attached to the current inventory dimension record rather than the return order line.

Repro steps:

1. Open a new or existing return order from Accounts Receivable / Common Forms / Return order details
   
2. Go to the lines of the order
   
3. Make one of the inventory dimension fields active, for example Configuration
   
4. Activate document management and a note.
   
5. Save and close the document management form.
   
6. Make a non-inventory dimension field active.
   
7. Activate document management, and observer that you don't see you note.
   
8. Close document management again.
   
9. Make again one of the inventory dimension fields active.
   
10. Open document management, and observe that the note now is displayed.
    

To fix the issue, the ReturnTable form should have a docCursor method similar to the docCursor method on the SalesTable form.