After a fruitful and enthusiastically received first DDC event, and, not the least important, after a number of new sponsors joining us we have started for the second DDC event. It's knocking on our door.

Nothing definitely set yet, but you might mark January 25, 2011 in your agenda with 2nd DDC event.

So what will be put on stage? That's fully up to you! Have a look at this communication on our LinkedIn group.

For interactive communication we have chosen to use LinkedIn so for those who did not yet join the Dutch Dynamics Community group on LinkedIn: subscribe yourself now and keep an eye on it.

Maybe needless to say: DDC is geographically bounded, i.e. Netherlands (Dutch!) only.

While chasing the recordings and presentations of the Microsoft Dynamics NAV 2009 R2 Developer Day 2010 I was pointed by an MS employee to this page: Microsoft Dynamics NAV 2009 R2 Partner Readiness Materials.

All NAV 2009 R2 material that has been released so far can be found here and all that still needs to (like recordings and presentations of November 10 R2 Developer Day 2010) will be published under these yellow marked headings soon:

On this day 1 Year minus 1 day since I started blogging I am glad to introduce you to this new star in the Dynamics blog-o-sphere: Microsoft Dynamics NAV Thoughts by Arend-Jan Kauffmann. It's good to know that apparently, as he writes himself, Mark and me did get him this far. And hope he will stay there. [8-|]

Well the start is promising adding a valuable extension to Waldo's solution to print RDL reports from the Classic Client.

Keep it rolling, AJ!

Although you might be aware now that any code in the OnLookup trigger will leave you as a developer to handle everything yourself, you have made the choice to write your own lookup functionality. As mentioned in my previous post OnLookup & OnValidate #1, you not only need to program the look up itself but also have to take care that the selected value is handed over to the field from where the user will perform the lookup, including its validation. Well ... except in the case of programming your lookup code on the relevant form control (see below).

Validation Schema

So what exactly does a developer need to take care of when needing to program lookup functionality?

Before we dive into that it’s worthwhile to read this section from the manual of our former "Programming in C/AL" course:

Some application objects have similar triggers, likewise the OnValidate trigger, which exists on tables as field trigger(s) or on forms as control trigger(s). When, after a user action, a value will be validated Attain will execute (in this order)

• system validation, i.e. checking the value against properties
• field OnValidate trigger (if coded)
• control OnValidate trigger (if coded)

The OnLookup trigger also exists as field and control trigger. The execution plan, however, is totally different.

• If no code has been implemented in either of the OnLookup triggers, the standard (system) look up will be performed
• If code has been implemented in both Onlookup triggers the control trigger will only be executed
• If only the field OnLookup trigger contains code the field trigger code will be executed

Based on this it’s interesting to do some investigations into the validation schema when performing each of the lookups given the fact that both at field and control level the OnValidate trigger has been populated.

Standard Lookup

When executing a standard lookup the 3 validation levels are executed in this order:

1. System Validation (TableRelation!)
2. Field - OnValidate
3. Control - OnValidate

Field Lookup

Executing a lookup programmed at field level only 2 validation levels are executed in this order:

1. System Validation
2. Field - OnValidate, if explicitly programmed!

No control OnValidate!

Control Lookup

And last but not least, when a lookup has been implemented on the control again 3 levels of validation are triggered (and executed):

1. System Validation
2. Field - OnValidate (does not need to be called explicitly; see below)
3. Control - OnValidate

OnLookup at Field Level

The code should consist of 3 steps:

1. Set the current value (this will make sure the current value is selected when the form is opened)
2. Look up the new value
3. Validate the value (using the field's OnValidate trigger)

Example

Customer No. - OnLookup()
Customer."No." := "Customer No.";
IF FORM.RUNMODAL(0,Customer) = ACTION::LookupOK THEN
  VALIDATE("Customer No.",Customer."No.");

OnLookup at Control Level

The code should consist of 4 steps:

1. Set the current value (this will make sure the current value is selected when the form is opened)
2. Look up the new value
3. Assign the new value to the variable (parameter!) Text
4. Return TRUE if the lookup was successful

Example

Customer No. - OnLookup(VAR Text : Text[1024];) : Boolean
Customer."No." := "Customer No.";
IF FORM.RUNMODAL(0,Customer) = ACTION::LookupOK THEN BEGIN
  Text := FORMAT(Customer."No.");
  EXIT(TRUE);
END;

Notes

• Unlike with the field trigger there is no need to validate the values returned. This is handled by the system because the OnValidate and OnAfterValidate triggers are called.
• This method can also be used for lookups on controls that have a variable as source expression (on a request form for example). By passing the value to the variable Text you ensure that the OnValidate and OnAfterValidate triggers of the control are called and you do not need to duplicate validation code. Preferably you would put the validation code and the lookup code in functions so the code can be reused (see below).

SMART Programming

Implement your lookup feature as one function on your table so that you can reuse the same function for the OnLookup triggers on the field and control(s).

On the table (field) you could have the following code

Customer No. - OnValidate()
// Update some other record(s) in the same table. This will require a form refresh

Customer No. - OnLookup()
VALIDATE("Customer No.",LookupCustomerNo("Customer No."));

LookupCustomerNo(CurrCustNo : Code[20]) : Code[20]
Customer."No." := CurrCustNo;
IF FORM.RUNMODAL(0,Customer) = ACTION::LookupOK THEN
  EXIT(Customer."No.");

On the form (control) you would have the following code:

Customer No. - OnAfterValidate()
CurrForm.UPDATE(FALSE);

<Control1000000> - OnLookup(VAR Text : Text[1024];) : Boolean
Text := FORMAT(LookupCustomerNo("Customer No."));
EXIT(Text <> '');

Notes

• In our example there is no need to explicitly add the FORMAT since type Code is automatically converted to type Text. However It is needed for other variable types.
• Add a CurrForm.UPDATE(FALSE) to the OnAfterValidate trigger on the control.
• Everything also applies to pages.

Muchas Gracias to ...

... my good old ex-colleague Gert Robyns (MSFT). Cheers, pal!

While looking for the recordings the Microsoft Dynamics NAV 2009 R2 Developer Day 2010 (haven't found them yet) I stumbled accross these presentation uploaded on mibuso covering a part of Wednesday topics. So for those who could not attend the Microsoft Dynamics NAV 2009 R2 Developer Day 2010:

• Dynamics NAV 2009 R2 Hot Topic - Overview
• Dynamics NAV 2009 R2 Hot Topic - What’s New for Developers in C/SIDE
• Dynamics NAV 2009 R2 Hot Topic - DotNet Interoperability

And also some topics not (really) covered on Wednesday:

• Dynamics NAV 2009 R2 Hot Topic - Online Payments Service for Dynamics NAV
• NAV 2009 R2 Hot Topic: RoleTailored Client for remote and roaming users

And of course you can read the resume's by my colleague Marco:

• NAVR2 Developer Day (Part 1) - What's new in C/AL in Nav 2009 R2
• NAVR2 Developer Day (Part 2) - .Net interoperability
• NAVR2 Developer Day (Part 3) - How to use the application testability features
• NAVR2 Developer Day (Part 4) - Dynamics CRM Integration
• NAVR2 Developer Day (Part 5) - SSRS (RDLC) Reports