I just did a simple test writing custom OnLookup() code that's giving some worrisome results that may affect more than just me. Hopefully I'm wrong or there's a way around this, or maybe everybody knows this is a "gotcha" except me!
The problem is that when there is custom OnLookup() code on a field in a table, the "OnValidate" and "OnAfterValidate" triggers on the Form do not get executed when you select a new value from the Lookup Form.
For a simplistic example :
I have the following have code in OnLookup() of the "Location Code" field in the Sales Line table.
VARIABLES:
MyLocationLookup Form My Location List
MyLocation Record Location
CODE:
CLEAR(MyLocationLookup);
IF MyLocation.GET THEN
MyLocationLookup.SETRECORD(MyLocation);
MyLocationLookup.LOOKUPMODE := TRUE;
IF MyLocationLookup.RUNMODAL = ACTION::LookupOK THEN BEGIN
MyLocationLookup.GETRECORD(MyLocation);
VALIDATE("Location Code", MyLocation.Code);
END;
- The form "My Location List" is a straight copy of Table 15 "Location List".
- I put a "Message" statement in the "Sales Order Subform" (Form 46) for the "Location Code" field, in the "OnValidate" and "OnAfterValidate" triggers.
- I run Form 42 "Sales Order", select an Item that has Locations, and select a Location. The new Location gets selected as expected, but my Messages at the Form level do not get displayed
- If I manually key in a new Location Code, then my Messages DO get fired from the Form level.
Thoughts/comments?
0
Comments
Instead, the code that you have in your Form Validate triggers could be moved to separate function and instead of Validate, you could call that function.
I have to say that I'm pretty suspicious of this design, however.
Are you *sure* this is the only way to accomplish whatever you are trying to do?
As for what I'm really trying to do - it boils down to the fact that I need to:
1. Set a variable before the Lookup form is called based on a value in a field in the current record.
2. Have the Lookup form's behavior be altered based on the value of that field.
3. Potentially run some alternate field validation code if the user selected a value from the Lookup form, based on certain circumstances.
I'm thinking that I'll have to live with these deficiencies. After all, NAV should not have any code in their form-level triggers, so there should be no problem if those triggers don't get called, right?
You don't have code to the table validation trigger - you just shouldn't try to automatically run code from teh form validation trigger. You can put your code in your function on the form, and call it your function (instead of validate) from the onlookup trigger. Shouldn't hold you back too much.
As you noticed, NAV doesn't really put code into the forms - and there is good reason for this. If you can avoid this, you should.
The basic principle is that your business logic should be data driven, not action driven. And the logic should be more or less the same if the initial data conditions are met. If you must have different behavior that is action driven, find some data that you can set, and use that to determine which code actually gets run.
The trigger has one parameter "Text" and return value of type boolean - was something selected or it was canceled...
MVP - Dynamics NAV
My BLOG
NAVERTICA a.s.
Original "problem" still remains - Form-level Validations do not fire when coding custom lookups at the Table level, and I really don't want to relocate my lookup code to the Form level.