Manually Add the Descriptor

Another task on this project had me update a label in the middle of a very large method that is called from 49 other places in D365.  Between changing 50 places in code as a set of derived classes and extensions or just customize the sys layer, I opted for the latter.  So, I created a customization project in a new model under ApplicationSuite.  The change took a few minutes.  I had to create new label files, write the labels, change the line of code.  I checked everything into VSTS correctly.  Then, a colleague did a test build and we found out that the new model that I created did not get registered by D365.  As a result, it could not be built from the Dynamics 365 menu.

A first pass at trying this had me export the project and emailing him the file.  My colleague then imported the file.  Then we found that the model was correctly created.  However, this did not seem like the right solution.

Contacting another colleague led me to the right solution.  Apparently, each model has a summary xml file under the Descriptor directory for the main model.  Customization models will have a file in the Descriptor folder of the model being customized (e.g. ApplicationSuite).  Extension models will have a Descriptor folder under the root (e.g. <<AosService>>\\PackagesLocalDirectory\<<Model Name>>.  In either case, the file for the descriptor needs to be manually added to VSTS.

Once a build machine gets the latest, the new model should be added.

Dynamics 365 -- Custom Lookups

I just started working on Dynamics 365 over the last few weeks.  It's been a bit of a rocky ride working with the new extension model.  I recently had a requirement to add the ProjId to the PurchaseReqTable form and limit the option to projects that have been assigned to the current user.

In order to do this, I created a lookup in-memory table and populated it with the correct data.  However, when I wrote the lookup code, I kept on getting an error,  “More than one form was opened at once for the lookup control.”  I looked and looked and looked and could not find a resolution.  I had thought it was because the ProjId has an EDT relation to the ProjTable and also had a predefined lookup form.  This would have meant that all of this would have be undone.  Furthermore, it would mean that the customized lookup would have to be used on all forms that used a ProjId.  This was not a good approach.  By sheer luck, I finally found a post at https://ievgensaxblog.wordpress.com/2016/05/16/ax-7-how-to-override-form-control-methods-using-extensions/  that explained how to suppress the system generated lookup.

My version of the code looked like:

[FormControlEventHandler(formControlStr(PurchReqTable, PurchReqLine_ProjId), FormControlEventType::Lookup)]
 public static void PurchReqLine_ProjId_OnLookup(FormControl sender, FormControlEventArgs e)
    {
        CPLookupTmp lookup;
        SysTableLookup sysTableLookup;
        FormControlCancelableSuperEventArgs csea = e as FormControlCancelableSuperEventArgs;
        ;
        lookup = CPLookupTmp::populatePropertiesForUser();
        lookup.setTmpData(lookup);
        sysTableLookup = SysTableLookup::newParameters(tableNum(CPLookupTmp), sender);
        sysTableLookup.addLookupfield(fieldNum(CPLookupTmp,CPId));
        sysTableLookup.setLabel('@CP:PropertyId');
        sysTableLookup.addLookupfield(fieldNum(CPLookupTmp,CPValue));
        sysTableLookup.setLabel('@CP:PropertyName');
        sysTableLookup.parmTmpBuffer(lookup);
        sysTableLookup.performFormLookup();
        csea.CancelSuperCall();
    }

The important point here is the new class: FormControlCancelableSuperEventArgs .  The CancelSuperCall method is what stops the base lookup form from being called.