F E A T U R EWRITTEN BY JACEK FURMANKIEWICZAdda powerful tool to your applicationdevelopment toolkitExpanding into other language markets presents an ample challengefor any PowerBuilder shop. In my case, we were faced withinternationalizing our existing sales audit application intoFrench (we’re based in Quebec, where French versions of applicationsare required by law), as well as UK English (there areenough differences in retail terminology between North America andEngland to make this necessary). Our European salespeople were alsotargeting clients in Germany and Spain and, realistically, we had to anticipatesupporting more languages in the future.Our application is fairly mature and quite large by now. Developmentstarted in early 1996 and the application now consists of over 55 PBLs withthousands of objects. Due to time pressures, we didn’t design with internationalizationin mind, and we faced the daunting task of designing aninternationalization solution for our application that could be implementedin a realistic time frame by our fairly small PowerBuilder developmentteam (six programmers). Also, it had to be easy to maintain and integratewell with the tools used by our translation team, who were also responsiblefor non-PowerBuilder applications (we have large Visual Basic and VisualC++ development teams for some of our other products).The internationalization solution recommended by Sybase is to use thePowerBuilder Translation Toolkit (included since version 6.5, if I remembercorrectly), but after initial investigation we decided we needed to build ourown custom solution. In a future article I’ll focus on our internationalizationsolution; in this article I focus solely on the use of resource DLLs in PB.14 PBDJ volume9 issue4www.SYS-CON.COM/pbdj/
Using Resource DLLs in PowerBuilderNot knowing much about Visual Basic orVisual C++, I investigated their internationalizationtools and it became apparent that theywere all based on the usage of regular Windowsresource DLLs (which, incidentally, is whatDelphi uses). A Windows resource DLL cancontain many different types of resourcesincluding graphics, video files, and text. Letyour imagination run wild as to how you canuse resource DLLs in your applications. In ourcase we were interested only in simple DLLsthat stored string phrases identified by numericresource IDs. In Windows it can be anunsigned integer, so you have up to 65,535possible unique resource IDs within one DLL,which was more than enough for our needs.As an added benefit, fetching stringresources from a resource DLL is extremelyfast. In my initial tests I was able to fetch over100 resources from a DLL in less than 200ms.These tests made it clear that this method waspreferred over any other we had considered(e.g., storing the phrases in the database or in atext file).To efficiently use a resource DLL the followingsteps must be completed:• The DLL has to be loaded into memory atstartup time.• String resources are fetched from it multipletimes during the user’s session.• The DLL is unloaded from memory whenthe user shuts down the application.Unfortunately, since PowerBuilder doesn’tprovide any built-in functions for loading DLLsinto memory or reading string resources fromthem, we’ll have to use Windows APIs toaccomplish this task. I would like to thank allthe fine folks in the PowerBuilder newsgroups(Roy Kiesler and the rest of Team Sybase in particular)for helping me with this.In essence, to load a DLL into memory youneed the following Windows API declaration(defined in PowerBuilder as an external localfunction):Function Ulong LoadLibraryA (stringlpLibFileName) Library "kernel32.dll"This returns a variable of type unsignedlong,which is your handle to the loaded DLL.To read a string from the loaded DLL you’llneed the following API:Function IntLoadStringA(Ulong hInstance, Uint UiD, refstring lpBuffer, int nBufferMax) Library"user32.dll"The first variable is your unsignedlong handleto the DLL as returned by the initialLoadLibraryA. The next variable is yourresource ID, the numeric identifier of the stringphrase you’re trying to retrieve, then a stringvariable (passed by reference) that will hold theretrieved text.The last variable is the maximum size of thestring you’re expecting. We initially set thisvalue to 255, but have run into some longerFrench phrases along the way and have nowchanged that to 512 characters.To unload the DLL from memory you mustuse:Function Boolean FreeLibrary (UlonghLibModule) Library "Kernel32.dll"once again passing it the unsignedlong handleto your initially loaded DLL.Listing 1 provides this entire process in PBcode. It illustrates all the steps needed to load,fetch a resource, and unload a DLL from memory.Obviously, this is not how we would beusing it in production, where the DLL is loadedonce at startup, used repeatedly to fetchresources from during the user’s session, andthen unloaded from memory at the end whenthe application is shut down.However, this listing clearly shows there’s nomagic in integrating resource DLLs intoPowerBuilder; it’s actually quite simple onceyou know which Windows APIs to use.More important, there’s no French-specific(or any language-specific) logic anywhere inthis code. All you need to do to support a differentlanguage is load a different languageDLL at runtime, depending on the user’s preferences.In our application, we currentlydeploy three DLLs: one with phrases in U.S.English, one with UK English, and one withFrench. To support other languages we onlyneed to create new DLLs with the translateddescriptions and give the user the option to usethat language at startup; that’s it. As you cansee, it’s much simpler than the PowerBuilderTranslation Toolkit approach of requiring differentcompilations of the EXE for each of thesupported languages.As an added benefit, the compiled resourceDLLs are extremely small. We have over 6,000phrases in our application (window titles, buttons,combo boxes, group boxes, messages,help, etc.); the English DLL is around 350KBand the French one is around 400KB. Thereforethe impact on memory usage is negligible.Creating Resource DLLsNow that we know how to use resource DLLsin PowerBuilder, we’re faced with the muchtougher issue of how to create them. Most ofthe other Windows development tools (VisualBasic, Visual C++, Delphi) come with their ownresource editors and compilers that allow themto create resource DLLs natively within theirIDEs. PowerBuilder comes with neither ofthese, so we had to look at third-party tools.The simplest solution would be to get aVisual Basic or Visual C++ license for each ofthe PowerBuilder developers, so they couldcreate the resource files and compile themfrom within those tools. However, that seemedlike a waste of money and no self-respectingPowerBuilder developer would be caught witha copy of Visual Basic on his or her PC (well, atleast not before VB.Net arrived recently).The first thing we needed to find was a(preferably free) C or C++ compiler that couldturn resource files (which are simple ASCII textfiles) into DLLs. In our production environmentwe settled on using LCC-WIN32, a free,open-source C compiler maintained by JacobNavia from France and available fromwww.cs.virginia.edu/~lcc-win32/.Make sure you not only download the com-www.SYS-CON.COM/pbdj/PBDJ volume9 issue415
Change language