I remember having seen this a while ago somewhere inside NAV but a colleague reminded me of this recently and I thought it’d make for a good post
Let’s get to it.
So yes, there is a way to accomplish this.
As most of us know by now, there are some variables within an object that are predefined for us by the system. Some of this variables can be “CurrPage”, “Rec” or “xRec”.
Well, there is another one a lot of us don’t keep in mind all the time. This variable is named: CurrFieldNo
How does CurrFieldNo work?
This variable stores the number of the field that the user has interacted with basically and its value can be accesed from a table. An example of this can be seen in Table 14 (Location) – Field 5714 (“Post Code”).
Post Code – OnValidate()
Postcode.ValidatePostCode(City,"Post Code",County,"Country/Region Code",(CurrFieldNo <> 0) AND GUIALLOWED);
In there we can see how CurrFieldNo is used as a parameter compared against a 0. If it is different (meaning the user has actually interacted with the table directly using a form/page) this will return true, otherwise it’ll return false. Simple huh?
Let’s test it!
In table 14 (Location) I’ve created a function that will make a message appear with the value of CurrFieldNo like so:
MESSAGE(MsgTxt,FORMAT(CurrFieldNo)); // MsgTxt is a TextConstant with the value "The value of CurrFieldNo is %1"
And I call this function from the OnValidate trigger of the Name field of the Location Table like so:
Name – OnValidate()
//Code4NAV.com.begin ShowCurrFieldNo; //Code4NAV.com.end
So when I enter a value in the name field directly from the location card, I get this pretty message:
Field number 2 is the Name field. Good! Everything works as expected.
Test CurrFieldNo – OnAction()
So even though we are validating the same field and we’re even doing it from the same card we use to modify manually the field, CurrFieldNo does not return the same value. So it clearly differentiates when it’s a user’s input or a system’s input in a standard way.
And of course, this happens when we’re validating the field from a different object (let’s say a posting codeunit). CurrFieldNo remains 0.
Last but not least… If we check the MSDN link for more info on CurrFieldNo, it clearly states the following:
So it makes me think it’s only a matter of time before this feature is removed. This might be a reason to try to avoid it. In the meantime we all know it’s there and can use it