Revision History: What's new in Version 6?
VBLM Version 6 ships in early April 2002 after more than one year of work. V6 is the first complete rewrite of VBLM since V1, and incorporates both major changes in form and function and dozens of refinements. Because I was rewriting it from scratch, nothing was off the table and I was able to implement many features requested but unfeasible in previous versions. Given the magnitude of the changes, and despite a great group of hard working beta testers, there are probably some bugs still lurking below the surface, though none that I know about. As always, let me know if you find one and I'll fix it ASAP.
So what's new in V6?
Pure 32 Bits
VBLM V6 is a pure 32 bit application, not a 16/32 bit thunking hybrid like its predecessors. I know it's long overdue, but hey, better late than never. The interface has lost its dated look, and I have strived to use 32 bit interface elements (treeviews, etc) to improve ease of use and functionality. Additional 32 bit benefits include the end of any practical limit on the size of the projects it can deal with, and liberation from the bugs in W2K's version of NTVDM.EXE.
No More Single Instancing
All previous versions of VBLM extracted and maintained a single copy of each unique string. While this meant that you only had to translate each string once, it also meant that you had to jump through awkward hoops in those not-infrequent cases where you needed to a) provide multiple translations for the same string, or b) translate some instances but not others.
While VBLM V6 still maintains only a single instance of each unique string extracted from your projects, it also maintains separate translations for each instance of each string, accessed with the new multiple instance editor. Thus, while it remains effortless to translate all instances identically, it is equally easy to translate all differently, or to translate some and not others. Doing so, moreover, does not involve any decision making at build time.
While this change may sound trivial, it entailed a fundamental change in VBLM's basic structure and function and a complete rewrite of the code into a much larger and more complex application. VBLM V6 keeps track not just of which strings occur in your code, but where they occur. Doing this once is relatively straightforward, but keeping track over time as your code changes is not. Moreover, strings can no longer be handled by themselves, say for importing and exporting -- each string must now be accompanied by its context, ie the line(s) of code in which it occurs.
Complete Support for Project Groups
You can now point VBLM at VBG files as well as VBP files, and create a single VBLM project that encompasses all projects in the group. Moreover, while VBLM maintains all strings in all projects in a single LMP file, when building a runtime switched version you can command it to build either a single language database for the entire group, or separate language databases for each individual project.
Complete Support for Different Project Types
VBLM V6 now provides "out of the box" support for the different sorts of projects you can build using VB. For instance, if your project group includes a parent app and several DLLs, VBLM can build a runtime switched version of the whole thing, in which the DLLs inherit the chosen language from the parent. While you can still modify the support code provided with VBLM to your heart's content, V6 comes with 21 separate runtime switching support files (V5 had 6).
Runtime Switching of Interface Dimensions
VBLM V6 allows you to define separate sets of interface dimensions, associate them with different languages, and switch between them at runtime. Thus your application's interface can grow on the fly to accommodate German, then shrink to handle English. You can create these sets yourself (just as you could extract/apply design-time dimension sets in V5), and V6 also includes a simple tool to create sets some percentage bigger or smaller than a base set.
Dimension switching is fully integrated with language switching -- there are no additional files. If, for example, you use a Resource format for your language database, the dimsets will be stored in the resource as well.
Overall, dim switching works well and, when switched on the fly, is very cool to watch. See runtime dimension switching for more info.
New Quick and Easy Ways to Exclude Unwanted Strings
V6 has nifty new ways to exclude strings that shouldn't be translated. Right click any string in the language table editor (LTE) and select any of three methods from the popup exclusion menu. In addition to the old capability to mark the string as excluded in the LMP file, VBLM can now prevent it from being extracted in the first place by choosing "Mark for Exclusion in Source File" or "Mark for Exclusion in List File." When you close the LTE, VBLM will automatically add VBLM directive comments to your source code for all strings marked for exclusion in source, and will create or add to a "string exclusion list file." In either case, the strings will be excluded during the next extraction.
The 'VBLM GET and 'VBLM SKIP comment directives have also been improved, with the ability to select individual strings in a line of code for inclusion or exclusion.
Improved Language Table Editor
The V6 LTE includes some handy new features, such as:
The multi-instance editor that opens to deal with multiple instances of a string. Using this editor you can copy a translation from one instance to all, select from a list of all existing translations, designate individual instances for exclusion, and more.
The dockable code window showing extracted strings in context can be positioned at any edge of the LTE. You can select code in the code window and mark the strings it contains for exclusion by right clicking and selecting from the popup exclusion menu.
The multiline editor for editing long strings.
A menu to switch between language tables without exiting and restarting the LTE
The ability to re-extract strings from within the LTE.
And more.
Language-Specific Settings
In V6, each language table maintains its own independent font settings, import and export files, build directories, VB command lines, and more. This is particularly useful when language tables use different character sets.
Drag and Drop
You can drop VB projects on V6 to start a new project, LMP files to open them, and LMX files to import them. See VBLM Drag and Drop
Improved Import/Export
The import and export processes have many new features. For example, you can import across languages, eg have a French file translated into German, and then import it into an English project. You can store version info in LMX files. There is an alternate, simpler syntax for command line importing. See Export options and Import Options for more information.
Improved Command Line Processing
All new features are available via command line switches, other switches have been added for older features that lacked them, and a few old switches have had their functionality improved. There are now over 60 command line options in total. Better yet, VBLM's command file processing capabilities have been expanded to include variables and flow control (OK, just a Stop statement). It's become clear to me over the years that many VBLM users like to do automated command line updates, builds, etc. I may be wrong, but I think V6 can do everything you can think of from the command line. Oh, it's got a new run silent switch, and an easy way to tell from a batch file when it has completed its work.
New Administrative Capabilities
V6 has many new features designed to help administer the ongoing localization of large, complicated projects. On the main window you'll see that V6 keeps track of last extraction date/time, last update date/time, last build date/time, and more. On the string extraction window, you'll see a summary of the last string extraction results, and in the extraction, update, import, and build logs you'll find a complete record of the localization process.
Limited Unicode Capabilities
Although VB itself still can't handle Unicode in the visible interface, VBLM V6 allows you to work with Unicode strings and take advantage of VB's Unicode-to-ANSI-via -the-system-codepage conversion algorithm. See VB, VBLM & Unicode for details.
As mentioned above, there are literally dozens of refinements, both large and small, throughout V6, including message suppression, screen commands, Yes to All buttons on dialogs, relative pathing, a compilation conditional, improved handling of related files, etc etc etc. As always, most of these things were suggested by VBLM users, so hats off! to all who took the time to send in their complaints, comments, and suggestions.
Welcome to VBLM V6!
Ben Whipple
See Also:
Importing LMP Files from Previous Versions
April 26, 2002
As expected, bugs cropped up as more people starting using VBLM V6.0. Most were minor, but the folks at XLSoft ran into serious problems trying to run V6.0 on Japanese versions of Windows. Fixing these problems entailed numerous changes, discussed in the new help topic Running VBLM on non-Latin Windows. It's ironic that VBLM V5, written mostly in VB3, had none of these problems while V6, written mostly in VB6, requires all sorts of workarounds to properly handle Japanese characters. That's progress?
Michiel de Bruijn and Gary Brown reported that using the LTE's whole word search feature caused errors. Fixed
Michiel also reported that VBLM generated an uncompilable resource file with duplicate ID strings. I traced this to a bug in the string index generation algorithm that caused incorrect ids to be emitted when multiple instance strings were both a) identically translated and b) marked as excluded. Fixed.
The hard working Michiel also reported that when "Edit/Copy Current to..." was selected in Multiple Instance Editor, Unicode strings got Ansi-ized. Fixed
Gary also reported that pasting translations in the LTE by using NT's built-in edit control popup menu did not fire the dirty flag, and hence changes were not saved unless the control also received at least one keystroke. Fixed (turns out that V5 had the same problem, but it was never reported). Fixed
The folks at XLSoft discovered that V6 did not like it when there were no printers installed. Fixed.
Claudia and Peter Anderwald experienced a subscript out of range error in GetStrings, caused by a control with more than 16 string properties. Fixed, as is the LTE's GoTo command problem, reported separately by Claudia.
I discovered that when you used the Language menu to switch languages within the LTE, the translation font was not being reset properly to the new language's setting. Fixed. I also discovered that when importing Unicode LMX files, string exclusions were not read properly and caused an input past end error. Fixed
I fixed most of these problems within a day or two of when they were reported, and between the official releases of V6.0 in eary April and V6.01 in late April, I uploaded interim builds 136-140. As of Build 141, I decided there were enough changes to merit a version increment. Build 141 still has a problem on Japanese Windows, but Japan has gone home for the weekend and I decided not to wait to hear from them before uploading V6.01. If you are running Japanese Windows, wait for Build 142 sometime next week.
That's it for now. As always, many thanks to those of you who took the time and trouble to make suggestions and help me track down bugs.
Ben Whipple
Build 147 5/14/2002
Build 147 includes revised methods for running on non-Latin systems, with small changes on the interface tab, the language table properties window, and the character set window.
Hats off to Evgeny Reingold for finding a bug (the LTE's "Select and Press Enter to Edit Multiple Instances" message was getting copied as a translation of the first instance of multi-instance strings) and telling me how to reproduce it. Fixed.
Artur Vieira and Lars Kiaer-Christensen independently discovered a problem exporting that occurred only on Win9x. The export file was getting truncated because the code was executing nonlinearly -- although the code sequence was write header, then write data, the header code executed so slowly on Win9x that the data would get written first, then the header would overwrite it. Fixed by inserting a delay before writing the data.
There is still a very weird problem with installation on Japanese Windows that can result in a corrupted exe. I'm working on this, but hope to be done shortly.
Build 150 5/16/2002
In build 150, the weird problem with corruption during installation on Japanese Windows is fixed, advice for running VBLM on non-Latin systems is updated, and VBLM V6 is finally ready for the Japanese market.
It turns out that the export delay loop (see Build 147) was not long enough for all circumstances. Rather than make it longer, I replaced it with logic that waits until the header write is complete, however much or little time that takes. I also made the wait occur only when running on Win9x.
Build 151 5/17/2002
Hats off to Marja Jaatinen, who reported from Switzerland that she was accustomed to using the LTE search function in V5 to find untranslated strings, but that it didn't seem to be working in V6. When she then checked Whole Word Search and tried again, she got an error message. Fixed.
I've also revised the installation routine to allow users installing a new build to preserve the INI file, skip the lengthy stuff, and just install the new exe.
June 2002
The folks at XLSoft reported pervasive problems importing LMX files when the source or translation language was named using Japanese DBCS characters. The problems affected both ANSI and Unicode LMX files, though in different ways. One problem was impossible to reproduce on an English machine, but I think I've finally figured them all out and fixed them. VB and Windows can do some very weird things with strings.
XLSoft also reported that VBLM was generating errors when they imported Unicode LMX files while running on Windows 98. That's because WIn9x doesn't support Unicode. VBLM now warns users who attempt to use its Unicode capabilities on Win9x.
Artur Vieira reported a nasty problem, where VBLM was supplying the wrong string index in a few places when building an RSV. This was another intractable problem that I could not figure out until he kindly sent me his source code. It turned out that if a) you had a multi-instance string, and b) you marked the first instance as excluded, then VBLM would not include any instances of the string when it wrote the language database or resource file. VBLM wouldn't export them, either. Fixed. As a bonus, I modified code to precalculate some index arrays that significantly sped up the build process.
Artur also reported that, when importing, only the first instance of a multi-instance string would be imported. It wasn't quite that simple; only the first instance of a multi-instance string would be imported when the instances all had identical context , ie the source code from which each identical string was extracted was also identical. Fixed.
Bill Seddon reported a series of SSOOR errors in FormattedStringIndex() when doing an RSV build with the string indexing method set to construct constants. This turned out to be an indexing error. Fixed.
While debugging using customers' project files (*.LMP), I discovered that VBLM's logging functions would complain if the project directory stored in the LMP file did not exist. Fixed -- it now logs to the LMP directory if the specified directory is not present.
Martin Sperlich pointed out a number of minor problems and inconsistencies in the interface, and also a problem when there was more than one instance of an excluded function in a single line of code (eg, MsgBox Format$(Now, "MM/DD/YY) & Format$(Now, "HH:MM")). VBLM would not process the second instance properly. Fixed.
Martin, along with someone else who I can't remember (sorry about that) told me that the presentation of multi-instance strings in the LTE was maddening because there was no way to know at a glance how many instances were translated and how many were not. They suggested that I change this, which I did: the LTE now displays this information for each MI string.
I think that's about it. As always, thank you all for your help. And thanks also for your many kind words about VBLM V6!
Ben Whipple