VBLM can build localized versions of your apps that use Microsoft's embedded resource format instead of WhippleWare's external language database. In fact, localization needs aside, you can use VBLM to convert a non-resource app into a "resourced" app in minutes -- just extract the strings and build an RSV using resources and the design language table.

Storing and fetching strings from a resource is very similar to storing and fetching them from a database, and VBLM's new resource capability is mostly an extension of the runtime switching capability that it has had since Version 1. There are, however, a few differences worth discussing:

Internal Resource vs External Database

A resource is compiled into the application. Thus you don't need to worry about distributing Language.Dat, and you don't need to worry about users screwing up the file. On the other hand, this also means that your users can't do the translation themselves, which is what some VBLM users like to do.

Using a resource also forecloses a distribution and installation strategy that many users like because it allows them to distribute a single multilingual version worldwide that, after installation, appears to users as speaking only their chosen language. Say, for example, that you've translated your project into 8 different languages. Instead of building a single LDB containing all 8 languages, however, build 8 separate databases instead, one for each language. Then have the installation program ask the user to select her preferred language and install the corresponding database. With only one language in the LDB, the app will load and use it transparently, without asking the user anything. This approach cannot be used if the strings are in a resource.

Other Stuff in the Resource

While Language.Dat stores strings and nothing else, a resource can be used to store all kinds of stuff: strings, icons, bmps, wavs, etc. Since VB apps are limited to using a single resource, this means that if you want to store other stuff, VBLM needs to know about it when it builds the resource. This is the purpose of the Resource File Template. If a file listed here exists, VBLM will copy all of its contents EXCEPT string tables into the resource file that it builds.

Indexing Considerations

Because Language.Dat stores strings and nothing else, VBLM's string indexing methods are a convenience, not a necessity, when building a language database (they are new in Version 5, and the V1-V4 worked just fine). In a resource, however, at minimum VBLM has to set the index base > 1 because resource id #1 is reserved for the app's default icon. Also, if you are using the resource file template to add additional stuff with their own resource ids, it's your responsibility, to configure VBLM so that the string indices generated by VBLM. don't conflict with these additional ids.

LoadResString() vs. VBLM_RTString()

While an app built to use a language database file must have a VB-coded function to return strings from the database (VBLM_RTString() is the one supplied), VB has the built-in LoadResString() function to return a string from a resource. The implications for the traditional RSV support code that VBLM adds to RSV apps are twofold:

image\DOT_SM.gif If you are building multilingual resource RSV versions of your app, you still need to add some support code to take care of language selection. The RSV support files supplied with VBLM uses a modified version of VBLM_RTString() to handle this. When language selection is complete, this version of VBLM_RTString() simply calls LoadResString() with the same index that was passed to it.

image\DOT_SM.gif If you are building single language resource RSV versions of your app, there is no need for VBLM to add either the RSV support form or module. Instead, you should just specify LoadResString as the string replacement function and clear the RSV support file selections.