A very common way to personalize the POS in Dynamics AX for Retail is to change the wording of the strings and labels in the product. We give you a very simple way to do this – no code changes or compiling necessary.
First of all, nearly every string that is used in the product resides in the POSResources.resources.dll file in the POS folder. The English (en-us) version of this file is in the root folder, and then we have one for all of the localized translations: fi\POSResources.resources.dll, fr\POSResources.resources.dll, etc.
When the POS application needs a string, it checks in one of two places (in this order):
- The dbo.POSISLANGUAGETEXT table in the POS database
- The POSResources.resources.dll file for the language currently being used
When a string is found, it gets cached for the remainder of the POS.exe lifetime. As a developer, this means that you cannot manipulate the strings at runtime – any changes that are made to the table do not get reflected until the next time the app is started.
To change the text of an existing label or string, all you need to do is populate three columns in that table: LANGUAGEID, TEXTID, and TEXT (the remaining columns are deprecated and are no longer used in the product).
LANGUAGEID and TEXT are pretty obvious. But where do you get the TEXTID from? There are a couple of tools you can use for this.
First of all, if you modify the POS shortcut and append a ‘-tr’ as a command-line argument, POS will run in a special developer mode where each string and label is prepended with the TEXTID. This will make the POS pretty ugly, but will allow you to find exactly which strings match up with which ID.
All you need to do is run the application until you see a string that you want to change and then add a line to the POSISLANGUAGETEXT table:
There are a couple of drawbacks to this approach. First of all, it requires you to “hunt and peck” around in the application to find all of the strings you want to change. Secondly, it doesn’t work very well when we use String.Format to do a search and replace on the string. For instance, this is string 13021: “Hardware profile: {0} was not found.” If you saw that message using the “-tr” trick, you would just see “Hardware profile: SomeProfile was not found.” You wouldn’t really know that you had to have the {0} placeholder in your string when adding it to the database table.
If you want a list of all strings in the product, you can use your favorite .Net Reflector tool (do a Bing search) to examine any of the resource DLL files. You should get something that looks like this:
From there you should be able to get a full view of all of the strings you might want to modify.
One other quick note on this topic: you should also use the POSISLANGUAGE table for any strings that you create from scratch. Find a block of un-used numbers and use that as a basis for your numbers. The Blank Operation sample plug-in uses 50700 as a starting number; that number through 50999 are currently un-used. Keep in mind that any numbers that you use may conflict with strings from other developers or possibly by future versions of the product.
Once you’ve added your strings to the table, you can use this method to grab strings from the table. We even have the localization translation built in for you!
MessageBox.Show(ApplicationLocalizer.Language.Translate(50702));
Localization and personalization of the POS is a very important part of any AX for Retail implementation. Hopefully you can use these tips to make that task a little easier.