Using #localmacro

Using the option #localmacro can reduce the size and also the visibility of your code.

For example, you create a while select statement and you have to control date range when some value are enable (so not all the time)

You can write this kind of code :

protected void doProcess()
{
    #localmacro.CheckDateDelivery
        (salesTable.DeliveryDate >= fromDate && salesTable.DeliveryDate <= toDate)
    #endmacro

    #localmacro.CheckDateDocument
        (custPackingSlipJour.DeliveryDate >= fromDate && custPackingSlipJour.DeliveryDate <= toDate)
    #endmacro
    ;

    while select salesTable
    where (!validatedOrTransmited   || ((salesTable.MySalesStatus    == MyStatus::Transmission
                                    ||   salesTable.MySalesStatus    == MyStatus::Validation))
    && #CheckDateDelivery)
    &&    (!prepared                ||  (salesTable.MySalesStatus    == MyStatus::Prepare
    && #CheckDateDelivery))
    &&    (!delivered               ||  (salesTable.MySalesStatus    == MyStatus::Delivery))
    exists join firstOnly custPackingSlipJour
    where   custPackingSlipJour.SalesId == salesTable.SalesId
    &&     (!delivered  || #CheckDateDocument)
    {
        // code here.
    }
}

AX2012 : Top 10 issues discovered from Dynamics AX Code Review

Description of the article :

Three years ago, the Premier Field Engineer team started the delivery of the Dynamics AX Code Review for Premier customers. It has been quite an interesting journey seeing many customization from different instances. Today I would like to step back and reflect on some of the most common issues.
If you are a senior developer on Dynamics AX, you may wonder how come these issues still exist. This is the reason why I decided to write this article. Developments are now shared among diverse team, sometimes across multiple partners and outsourced to vendors, meaning different skills and processes. Therefore such well known issues still remain in production when customized best practices rules and internal review are not properly defined.

The following list is not exhaustive and is only based on our experience from the field.

Find the complete MSDN post here : http://blogs.msdn.com/b/axinthefield/archive/2014/02/18/top-10-issues-discovered-in-the-dynamics-ax-code-review.aspx

Blocking copy / Ctrl+C in a grid

I’ve hear that this request is often asked.

So there is a little piece of code to block all copy of data in a grid (for all form)

If you want to do this only on one form, you need to overwritte the method taks in the form

 

For my case, you need to select the method “task” on the class “SysSetupFormRun’ and write this:

FormControl form;
//standard code
if (_p1 == #taskCopy)
{
    form = this.control(this.selectedControl().containerId());
    if (form && form.handle() == classNum(FormGridControl))
    {
        //warning('Cannot copy on this grid!');
        return 0;
    }
}
ret = super(_p1);
return ret;

And for disable the copy on a specific field :

In the code I use this : this.selectedControl().containerId()
The method selectedControl return the fields on which we are, so you need simply use this : (with ItemName as fieldName from SalesTable form)

   if (_p1 == #taskCopy)
   {
       form = this.selectedControl();
       if (form.name() == 'ItemName')
       {
           //warning('Cannot copy this field!');
           return 0;
       }
   }

My original post : http://blogs.msdn.com/b/sebastien-petre/archive/2013/02/21/blocking-copy-ctrl-c-on-a-grid.aspx

AX 2012 – Included columns

You will find the link who explain the process :

http://dev.goshoom.net/en/2012/04/included-columns-in-ax2012/

Little part of the post:

Included columns is a feature of SQL Server (since version 2005) related to indices.Thanks to it you can attach additional fields to an index that are not used for searching (so they don’t have to be maintained so expensively) but that can be used by database server to return data. If all columns being returned by a query are included in an index, database server can directly return data and it doesn’t have to touch the table itself (and that saves time, of course).

 

Included columns also have additional advantages:
  • can be added to a unique index without influencing uniqueness
  • support even (some) types that can’t be used in normal indices
  • don’t count to the limit of number of index columns (16)
  • don’t count to the limit of index size (900 bytes)

 

The following (logical) restriction apply:
  • are always at the end of index
  • the index must contain at least one “normal” (key) column
  • can’t be used in clustered indices
Of course, even included columns have impact to index size so they can slow down operations with the index and consume disk space.