An international solution should be able to co-exist with any other add-on. License wise this has been enabled by specific objects ranges assigned to the add-on which assures that CSIDE objects – i.e tables, table fields, forms, reports, etc. – do not conflict (however see note 1).
Unfortunately NAV does not have an automatic mechanism that prevents that lower level objects in your solution, like controls and variables – including functions and text constants -, might conflict with other solutions. So you have to make sure controls and variables have ids within your number range. There for you need to enable the GetUidOffset function in COD1. That’s what we did for our solutions.
Some background – Version 3.xx
With version 3.xx, and until version 4.xx, the only way to do this was:
- to trust on the development license you had (see note 2) and/or
- manually assign a specific id to a control/variable in your add-on range
This applied for both development partner and NTR – Navision Territorial Representative – (see note 3).
Some more background – Version 4.xx
Version 4.00 was the first NAV release under the umbrella of MS. The first release where one team had to take care of multiple localizations. Like our WEMEA team that took care of 15 of them (AT, BE, CH, DE, ES, FI, FR, GB, GR, IT, NL, NO, PT, SE, TR). The first release where single developers were going to write code for multiple countries. And instead of forcing them to switch license whenever they had to change from one country to the other a new technical feature was designed, i.e. function 212122 in COD1: GetUidOffset.
Veterans among us will recall that in the first major and minor releases of 4.xx this function could be found in COD1, but after that the NAV build did clean it from the database before a release and a lot of you felt like having been taken away one of your major toys not knowing/being aware you could easily revive it by simply adding the code to COD1. Read more here.
If GetUidOffset does not exist in COD1 the client will fall back on the range that applies for thecountry in your licens (see note 2).
Notes
- Reserved object ranges assure that object ids are unique, they however do not assure that object names are unique. Thus add-ons could collide due to duplicate name usage.
- With version 3.xx (starting with Navision Solutions!) every control/variable was automatically assigned a unique id taken from a range depending on the country your license was issued for. I know we had this table in our localization guide at GDL listing all countries with their id range, but as non-MSFT I have no longer access to that. Searching on the web unfortunately did not help me. So I dusted my pile of old product CD and found it listed in the What’s New in C/SIDE 3.10 document. Making me smile and think of days gone by as I was the initial author of this doc. [:)]
Developer
From
To
Navision HQ
0
9,999
Navision Netherlands
1,000,000
1,009,999
Navision Belgium
1,010,000
1,019,999
Navision USA
1,020,000
1,029,999
Navision Canada
1,030,000
1,039,999
Navision United Kingdom
1,040,000
1,049,999
Navision Iceland
1,050,000
1,059,999
Navision Denmark
1,060,000
1,069,999
Navision Sweden
1,070,000
1,079,999
Navision Norway
1,080,000
1,089,999
Navision Finland
1,090,000
1,099,999
Navision Spain
1,100,000
1,109,999
Navision Portugal
1,110,000
1,119,999
Navision France
1,120,000
1,129,999
Navision Italy
1,130,000
1,139,999
Navision Germany
1,140,000
1,149,999
Navision Switzerland
1,150,000
1,159,999
Navision Austria
1,160,000
1,169,999
Navision Poland
1,170,000
1,179,999
Navision Lithuania
1,180,000
1,189,999
Navision Latvia
1,190,000
1,199,999
Navision Estonia
1,200,000
1,209,999
Navision Russia
1,210,000
1,219,999
Navision Czech Republic
1,220,000
1,229,999
Navision Slovenia
1,230,000
1,239,999
Navision Australia
1,240,000
1,249,999
Navision New Zealand
1,250,000
1,259,999
Navision Singapore
1,260,000
1,269,999
Navision South Africa
1,270,000
1,279,999
General customer modifications
1,000,000,000
1,000,999,999
Add-ons and converted objects
1,100,000,000
1,199,999,999
Update 2011-04-29: accidently I did find an online version of this list here today. Now I wonder why I did not come across it before. [:$]
- In pre-MS times a generic localization of NAV was the full responsibility of the Navision NTR. Assignment of control/variable ids in these localizations was based on the same principle as what applied for partners. For that reason many (standard) local features like Telebanking (NL), Cartera (ES), Simulation (FR), still have controls/variables in the country range as listed above.
- GetUidOffset only provides you with a starting number for your ids, but does not help you to keep them within a range; i.e. there is no guard on the upper limit. This might result in controls/variables having ids that are outside of your reserved number range. CSIDE does allow that and most probably you will never have an issue as the next range (following yours) is reserved for an add-on that might never be used alongside your add-on.
- A variable id is assigned within its context, meaning that it’s unique within the local or global context the variable is defined for. You might have two variables in the same object with the same nameand/or id as long as one is global and the other local.
Valid observations, Thomas.
Note that what I am writing in my BaIS sequel are thoughts and considerations. And of course these are the basis to our decisions, but your free to choose. 😉
Good to hear and fully agree with "your annoyance" as you might have concluded from some of my earlier posts of which most of them eventually ended up as incidents reported to MS. And … resulted in some kind of fix. So if possible I would encourga you (and anyone else) to report everything to MS. Let them know, bug them, and push it to the limit (in a positive way).
If you don't want to do that yourself be free to ask me.