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:
While I was still fighting to get my reinstalled laptop doing what I wanted to, Mark took the lead in announcing our newborn dynamics community contribution: Dutch Dynamics Community. So now at the end of the day, though still fighting my laptop, it's my time for some undouble dutch on this.
I am really thrilled about this as it feels like something so akin to me; a custom made suite; my grandmother's tomato soup ... Well, so much more comes to mind. And I have to be honest, not in the least it fell into to place due to my counter parts in this: Arend-Jan Kauffmann and Mark Brummel. Thumps-up, guys!
For those who have been following my blogs, for those who have been attending my Solution Developer classes in the past, for those who have been my fellow team members in recent years this must be some kind of deja-vu. The suite that fits me so well. To share, not reinvent the wheel, and dive into subjects.
Our initial focus will be close-to-home: that what we 3 have in common and where we feel there was a gap left since MS stopped organizing the so called Pizza Sessions years ago; i.e. the technical side of Dynamics NAV. (See also my LinkeIn thread Pizza-sessies voor NAV developers?.) For the coming year we have in mind to organize 4 to 5 evenings with approx. 2 parallel technical sessions on Dynamics NAV, freely attend-able to all Dynamics pros. But we definitely want this to be a community, a platform the can serve the needs of those that want and can be part of it within the whole Dynamics domain, technical, functional, process oriented, user or implementator.
So we will start with our first session on October 26, 18:00h. With pizzas! And of course some good talks by Arend-Jan and Mark. read more on this on Mark's blog. Want to subscribe to it? Send us a e-mail: firstname.lastname@example.org.
As the whole thing is in its take-off phase we are getting into gear regarding sponsoring. However, I would like to point out that the starting up of this new initiative would not have been possible without the sponsor promising of a couple of Dutch Dynamics partners who's names (logos) will soon shine on our web site. And yes, ... we are looking for more sponsors to make this a real joined and fruitful community.
To our Belgian Dynamics Community fellows: thanx for letting us use your logo. We decided to change the colours a bit.
... write us at email@example.com!
So we had decided to extend one of our add-on modules. And as it had been measured on the short side we had to apply for an extension of the number of objects. Simple as that ... it seemed.
So how to do that? PartnerSource surely would be of help, we thought. So we typed add-on extension. Nope. Add-on registration, bingo!
One of the two top hits did lead us to Microsoft Dynamics NAV Add-On Registration page which contains good info on the whole process of registering your add-on. Yes, I even pushed the thump-up.
The heart of this page (and the process) are these two documents:
Self-explanatory titles, but still a lot to read bearing in mind that we only needed to extend the number of objects. Just have a look at the table of contents.
Well, it makes sense altogether when you start with an add-on first time. The spooky things to us were the section 6 and 7. Well actually not the sections as such but executing on them. And here is where the title of this blog post comes in view. It felt like being sent from one counter to the other, which, as matter of fact, were manned by the same MSFT.
First you need to apply for the object range (extension) uploading your request form on a Call Logging Tool (CLT) incident. This '... may take up to 3 working days to complete this step', as the guide says. Counter one!
Then you need to apply for the 'creation of the Add-on Module', i.e. a module id will be assigned to the object range. Counter two!
Eventually we had to do this for a couple of add-on's and I am still astonished by this. OK, only two counters, that's still one too much. For the extension we have two known's, being the module id and the number of objects (to be added), and one unknown, being the number range. Can't this be handled in one request?
In my search for a NLD version of the Microsoft Dynamics NAV 2009 RoleTailored Client Terminology slide deck I was pointed by the Dutch MBS PMM Aldert Kadijk to a site I had never been aware of: Microsoft Language Portal.
Next to the fact that you can search for any ENU term and it's local translation (and vice versa) it provides a number of downloads:
Wasn't able to download everything yet, but the Style Guide for sure is worthwhile for those who write user assistance documentation like Online Help.
Just entered some terms to see the results. Funny to see this one:
Do you see what I mean? Navision is still there at MS.
And so it seemed Mark and I were going to end up in a "Yes, you do" ... "No, you don't" quarrel about the need to reset object properties after importing a UI translation.
Let's just take the perspective that we were at cross-purposes; langs elkaar heen praten as we say over here. Having taken the discussion on a private mail thread it even took a while before that became clear. And you know, in a way we were both right. Rereading my posts on translation I have no problem to take the blame on me, as I talked about UI and translation, about tools and object properties, about captions and efficiency, but failed to give a complete enough picture of the UI translation process as such. A good enough subject to elaborate more on later. Or actually make a start with now by explaining the difference between a translate export and a language module, let's say, respectively, my perspective and Mark's.
You create a translate export in NAV from the Object Designer by selecting Tools > Translate > Export. This will create for all selected objects a file with all translatable strings, identified by an ID and the text string. Without going in to details I'll do with an random example:
T3-P2818-L30:Payment TermsT3-P8629-A1033-L999:Payment TermsT3-P4960-V1000-P2818-L30:PaymentTermsTranslationT3-F1-P2818-L30:CodeT3-F1-P8629-A1033-L999:CodeT3-F2-P2818-L30:Due Date CalculationT3-F2-P8629-A1033-L999:Due Date Calculation
This file is the basis for making a translation of the UI of your application. Taking the example strings from table 3 you can see we only have ENU (US-English) captions, i.e. lines having the -A1033- token in it (1033 is the Windows id for ENU) and no lines with any other language token.
Using a translation tool to translate from ENU to SVE (Swedish - Windows id 1053) should eventually give you the following strings:
T3-P2818-L30:Payment TermsT3-P8629-A1033-L999:Payment TermsT3-P4960-V1000-P2818-L30:PaymentTermsTranslationT3-P8629-A1053-L999:BetalningsvillkorT3-F1-P2818-L30:CodeT3-F1-P8629-A1033-L999:CodeT3-F1-P8629-A1053-L999:KodT3-F2-P2818-L30:Due Date CalculationT3-F2-P8629-A1033-L999:Due Date CalculationT3-F2-P8629-A1053-L999:Förfallodatumformel
To get this translation available in your application you need to import it into NAV by selecting the translation file through Tools > Translate > Import. Importing these strings into the application will update object properties is mentioned in How-to: Reset Object Properties After Importing a UI Translation.
Next to creating a translation as described above NAV also knows so called language modules. This is how the Application Designer's Guide describes a language module:
A language module contains the same information as the Translate Import/Export data files. However, a language module contains text for only one language layer. Language modules are binary files that you cannot modify with external tools.You can import a language module by clicking Tools, Language Module, Import, and you can export one by clicking Tools, Language Module, Export.
On Customer/PartnerSource MS provides the language modules for the whole range of languages NAV is being released for. For example for 5.0 SP1. Note that, as MS states it:
Each language module only covers the functionality for the one specific language, e.g. the Danish language module contains all Danish strings for Danish functionality. It does not contain Danish strings for e.g. French functionality.
Opposed to importing a translation, importing a language module will not update object properties, i.e. leaves them like they already were.