Adding a custom lookup to a form control

In Dynamics AX one way you can add a custom lookup or drop down list to a form control by overriding the lookup method of the control.  Below is some example code for doing this.

public void lookup() 

 { 

     //This lookup basis the list criteria on information in 2 tables

     //All display fields come from Table1, Table2 is used for limiting criteria

     //super(); 

     //This Next Line initializes the the sysTableLookupClass

     sysTableLookup          sysTableLookup  =

                     SysTableLookup::newParameters(tableNum(<TABLENAME1>), this); 

     Query                   query           = New Query(); 

     QueryBuildDataSource    qbdsTbl1, qbdsTbl2; 

     QueryBuildRange         qbr; 

     ; 

     //Add Tables to the data source

     qbdsTbl1      = query.addDataSource(tableNum(<TABLENAME1>)); 

     qbdsTbl2     = qbdsTbl1.addDataSource(tableNum(TABLENAME2)); 

     //Add Query Ranges to limit List records     

     qbr = qbdsTbl1.addRange(fieldNum(<TABLENAME1>,<RANGEFIELDNAME1>)); 

     qbr.value(<CRITERIAVALUE>); 

     qbr = qbdsTbl1.addRange(fieldNum(<TABLENAME1>, <RANGEFIELDNAME2>)); 

     qbr.value(<CRITERIAVALUE>); 

     qbr = qbdsTbl1.addRange(fieldNum(<TABLENAME1>, <RANGEFIELDNAME3>)); 

     qbr.value(<CRITERIAVALUE>); 

     //Since we have multiple tables in the query turn on relations

     qbdsTbl1.relations(true); 

     //Add Ranges to the Table2

     qbr = qbdsTbl2.addRange(fieldNum(<TABLENAME2>, <RANGEFIELDNAME4>)); 

     qbr.value(<CRITERIAVALUE>); 

     qbdsTbl2.relations(true); 

     //The next 2 lines actualy adds the fields that will be displayed in the lookup grid

     sysTableLookup.addLookupfield(fieldNum(<TABLENAME1>, <DISPLAYFIELDNAME>)); 

     sysTableLookup.addLookupfield(fieldNum(<TABLENAME1>, <DISPLAYFIELDNAME>)); 

     //Hand the created query to the sysTableLookupClass

     sysTableLookup.parmQuery(query); 

     //Display the drop down 

     sysTableLookup.performFormLookup(); 

 }

Another example single table with field and table names instead of variable place holders

//Single table example with actual table and field names instead of  place holders

 public void lookup() 

 { 

     //This lookup basis the list criteria on information in 2 tables

     //super(); 

     sysTableLookup          sysTableLookup  = 

                 SysTableLookup::newParameters(tableNum(salesBillOfLadingJournalTable), this); 

     Query                   query           = New Query(); 

     QueryBuildDataSource    qbdsJT, qbdsBLR; 

     QueryBuildRange         qbr; 

     ; 

     qbdsJT      = query.addDataSource(tableNum(salesBillOfLadingJournalTable)); 

     qbdsBLR     = qbdsJT.addDataSource(tableNum(salesBLReservation)); 

     qbr = qbdsJT.addRange(fieldNum(salesBillOfLadingJournalTable,isMaster)); 

     qbr.value(enum2str(noYes::No)); 

     qbr = qbdsJT.addRange(fieldNum(salesBillOfLadingJournalTable, custAccount)); 

     qbr.value((salesBillOfLadingJournalTableMaster.CustAccount)); 

     qbr = qbdsJT.addRange(fieldNum(salesBillOfLadingJournalTable, masterBLID)); 

     qbr.value(""""); 

     qbdsJT.relations(true); 

     qbr = qbdsBLR.addRange(fieldNum(salesBLReservation, blOpen)); 

     qbr.value(enum2str(noYes::Yes)); 

     qbdsBLR.relations(true); 

     sysTableLookup.addLookupfield(fieldNum(salesBillOfLadingJournalTable, BillOfLadingID)); 

     sysTableLookup.addLookupfield(fieldNum(salesBillOfLadingJournalTable, salesID)); 

     sysTableLookup.parmQuery(query); 

     sysTableLookup.performFormLookup(); 

 }

Sales order creation at the most basic with ax Classes

 

Programmatic creation of a sales order can range from complex to easy, this is by far the Easy example making use of the axSalesTable and axSalesLine classes you dont get much easier than this.   The example should be a good starting point the ID’s used are part of the standard Demo data.

static void CreateSalesOrder_Job(Args _args)

{

    axSalesTable axSalesTable;

    salesID salesID;

    axSalesline axSalesLine;

    ;

    ttsBegin;

    axSalesTable = new axSalesTable();

    axSalesTable.parmCustAccount('1101');

    axSalesTable.save();

    salesID = axSalestable.salesTable().SalesId;

    info(salesID);

    axSalesline = new axSalesLine();

    axSalesLine.parmSalesId(salesID);

    axSalesline.parmItemId('7009');

    axSalesLine.parmSalesQty(10);

    axSalesLine.save();

    //Line with dimensions

    axSalesline = new axSalesLine();

    axSalesLine.parmSalesId(salesID);

    axSalesline.parmItemId('1001');

    axSalesLine.parmSalesQty(1);

    axSalesLine.axInventDim().parmConfigId('HD');

    axSalesLine.axInventDim().parmInventSizeId('42');

    axSalesLine.axInventDim().parmInventColorId('02');

    axSalesLine.save();

    ttsCommit;

}

Programmatic choice of select statements and the Next operator

Occasionally I’ve had situations where using a while select statement to loop through a set of records and needed the fields used in the selection criteria to be dynamic or the entire selection statement to be chosen dynamically based on arguments passed to the method.  A simple example would be for a set of logic to sometimes act on a group of records but other times act on a single record.  Dynamics AX X++ offers a slick way of dealing with this that is used in the standard application code but is still pretty obscure.  The following method demonstrates using a variable select statement based on passed in arguments and using the NEXT keyword to move the record set forward.  In this example we’re just outputting the Item ID to an info log but you could get much more creative….

void SelectNextSample(salesID _salesID, inventtransID _inventTransID = '')

{

    salesLine salesLine;

    ;

    if(_inventTransID)

    {

        select salesLine 

            where  salesLine.SalesId == _salesID

                && salesLine.InventTransId == _inventTransID;

    }

    else

    {

        select salesLine

            where salesLine.SalesId == _salesID;

    }

    while(salesLine)

    {

        info(salesLine.ItemId);

        next salesLine;

    }

}

I realize that the above is a simplistic example but it does demonstrate the ability in X++ to determine at run time the exact select statement that will be looped through against your Common object, although in reality the above example does not require variable select statements at all, a bad example in practical use but does show the general construct.  Below is another example, again very simple output of an info log but the variance in the select statements is greater, here it is a difference of acting logic on all sales lines with particular item ID vs. just sales line with the given item ID for a specific warehouse.   In the case below the content of the inventDim source is not needed in the logic portion of the code so when criteria restriction on inventLocationID is not needed we can have a simpler selection statement.   We could enjoy the same dynamic flexibility at run time using a query objects but the point here is to really demonstrate the use of the Next operator with variable selection statements.

void SelectNextSample2(itemID _itemID, inventLocationID _inventLocationID = '')

{

    salesLine salesLine;

    inventDim inventDim

    ;

    if(_inventLocationID)

    {

        select salesLine 

            where  salesLine.itemID == _ItemID

        Join tableID from inventDim

            where  inventDim.InventLocationId == _inventLocationID

                && salesLine.InventDimId == inventDim.inventDimId;

    }

    else

    {

        select salesLine

            where salesLine.ItemId == _itemID;

    }

    while(salesLine)

    {

        info(strFmt('%1, %2', salesLine.SalesId, salesLine.ItemId));

        next salesLine;

    }

}