BaIS #4: GetUidOffset

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:

  1. to trust on the development license you had (see note 2) and/or
  2. 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

  1. 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.
     
  2. 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. Smile

     

    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. Embarrassed
     
  3. 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.
     
  4. 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.
     
  5. 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.
Anonymous
  • 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.

  • No, don't misunderstand me. I fully agree with what you say and I'm following this concept for years already.

    Anyway it is annoying to see IDs changing in standard where not necessary and see IDs coming in which make merging as difficult as it was in the good old Navision Financials times (where additional custom controls have been just numbered following the ones already in the object.

  • 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. ;-)

  • Why should we worry about ID's if Microsoft doesn't?

    With 2009R2 we received plenty of objects which have controls in the range used by a noremal DEV license.

    Bad Job Microsoft. A simple Beyond Compare would have avoided that.

Related
Recommended