The other day I was on a thread where the enigma of coding the OnLookup trigger came around the corner. It reminded me that this used to be a rewarding subject during the Solution Developer courses in those days. I would show the students a simple table/form combination with one of the fields having a table relation enabling you to perform a look up to the related table. So I would press the look up button, but nothing happened.
“How can this be?” I would proclaim.
Generally, prior to that, I would have discussed the typical behavior of the OnLookup trigger. Now phrasing my own words from the course manual:
Once you have written code in the OnLookup trigger Attain (NAV!) takes of his hands. Displaying the LookupForm and validating the selected value is all to the developer to handle.
Consequently, armed with that knowledge, the students would direct me to the OnLookup trigger of that field, assured that we would hit some code there that clearly prevented the field to be populated with the selected value. But … amazement all over as we discovered that the trigger apparently did not contain any code.
The attentive student, however, would notice that the relevant OnLookup trigger contained 2 empty lines instead of one. “Got you! Just scroll a bit to the right, please.”
Surprise! OK, framed!
Thus we removed the code. Issue solved. Close and compile. Rerun the form. Press the look up button and … no look up form!
Back to the trigger: no line of code, no “hidden” comment, nothing … it seemed.
An already experienced developer or even a smart newcomer then might have started to mumble something about global variables.
Empty. No, uhhh, … local variables!
Hit the mark!
So any code, including comments – out commented code! -, variables or text constants, will overrule the default look up functionality.
More on the OnLookup (and OnValidate) trigger in a next post.
Already want to read more on the OnLookup/OnValidate enigma: