Version 5.0

VBLM Pro Version 5.0 ships in April 1999, ~4 months behind schedule (oops). The primary reason for the delay is that I did not realize in advance just how complicated adding full VB6 support was going to be (the secondary reason, as those who've read my whiny web site already know, is that I quit smoking) . VBLM had always been easy to upgrade for new VB versions, and I did not understand that this time was going to be different. In fact, I was planning a minor upgrade, to Version 4.1, and thought it would take a month to complete. Ha! This plan died about an hour after I got started, when it finally sank in that property strings stored in the definition section of the new designer files (*.dsr) were fundamentally new elements, and that I would have to perform major surgery on almost every part of VBLM to accommodate them (Dsr files were actually introduced with VB5, but they were undocumented and seldom used -- nobody cared that VBLM 4 didn't support them. However, they are central to VB6's new feature set).

Now for the good news. Since I had to make extensive changes for VB6 anyway, I decided that it was a good time to seriously consider major new features and capabilities that users had requested but that I had resisted because of the amount of work involved. And after considering them, I did in fact implement almost all of them. So as of Version 5 VBLM now supports resource files, for example (about time, eh?), and has many other new capabilities as described below. Of course, I also fixed the handful of bugs reported since the release of V4.02.

Full VB6 Support

VBLM now supports all of the new features, file formats, language elements, etc. in VB6. If you can build it in VB6, you can localize it with VBLM V5, with one sort-of exception: Of course, VBLM5 also remains fully compatible with all previous versions of VB except VB1. See Working with Designer Files for details on how VBLM works with these abstract and powerful new file types that are central to most of VB6's new features.

Resource File Support

VBLM can now build localized versions of your apps that use Microsoft's resource file format instead of WhippleWare's proprietary external language database. In fact, localization aside, VBLM can convert a non-resource app into a "resourcized" app in minutes. See Using Resource Files for more info about what is by far the most requested new feature in VBLM (heck, since resource files are Microsoft's officially recommended way to support localization, I've had people requesting them who didn't even know what they were).

RSV String Indexing Enhancements

When any previous version of VBLM built a runtime-switched version of your app, it always numbered the strings sequentially starting at 1, and inserted these numeric literals as the argument to the string replacement function (VBLM_RTString() by default). As of V5, you can specify both the base and the increment so that, for example, the string indices start at 1000 and increment by 10. You can also configure VBLM to insert symbolic constants instead of numeric literals and include a file defining them. See RSV: String Indexing Method for more info, and hats off to Walter Keutgen for the idea.

RSV String Replacement Function Enhancements

VBLM Version 4 gave users the ability to override the default VBLM_RTString() string replacement function and provide their own. V5 takes this one step further, with the ability to override the argument list for the function as well. VBLM now uses a user-definable template to construct the arguments passed to the function, so power users can configure VBLM to pass more than the string index. Users can also instruct VBLM to replace all extracted strings, not just translated strings, with function calls. See RSV: String Replacement Function for more info.

Localize Application Property Strings Stored in VBP Files.

Early versions of VB stored almost nothing except a file list in the project file (*.mak/*.vbp), and consequently, VBLM has always treated the project file as nothing more than a list of files. However, as VB has matured, the project file has become the repository of much more, including application property strings such as the name, title, producing company and comments. Hats off to Richard Braeken, who suggested that VBLM should be able to extract and replace these strings -- now it does. See Localizing Application Property Strings for details.

Major Expansion of Command Line Options

Although I have tried to make VBLM's functionality available for command line operation, it has often seemed that no matter what switches I add, some user always asks for one that I didn't. Ron Gordon wrote "We found it somewhat surprising that there is no command line switch that permits one to specify the Language Database File Name." Henry Choy was disappointed that there was no way to command LMX file imports. Well, users are now going to have a much harder time thinking of command line switches that VBLM should have but doesn't. VBLM4 had 12 switches (which I thought was pretty extensive), but Version 5 now has 43! See Command Line Options for info on how you can now control almost every aspect of VBLM's behavior from the command line.

Expanded Aliasing

Version 4 introduced target directory aliasing, whereby certain symbols would be expanded with a value during a build -- %Language%, for example, is replaced with the name of the language being used. In V5, you can also use these symbols in the name of the language database, the name of the new project to build, the name of the resource template file, and in the translations of application properties. See Aliasing for more info, and thanks to Larry Gajdos and Juha Tenhunen for the idea.

Non-standard File Extension Trapping and Mapping

Previous versions of VBLM relied on project file extensions almost exclusively to classify project files by type (form, class, etc), and generally treated all non-standard extensions as modules. I recently discovered that the VB docs are wrong when they say that all post-VB3 file types must be named using the standard extensions; you can indeed use other extensions, and VB will usually figure out the correct file type. VBLM, however, would not. As of V5, the first time VBLM encounters a non-standard file extension in a project, it will ask you to confirm the file type, and whether or not the extension always indicates this file type. Over time, VBLM will thus build a list of all the extensions you use, and what file types they indicate. See Non-standard File Extension Mapping for more info.

VBLM GET Directive

Three users -- Shengbo Liu, Matt Gerassimoff, and Richard Hardman -- suggested that VBLM needed the opposite of the VBLM SKIP directive, ie a trailing comment in source code that would force VBLM to extract a string from a line of code in a file or procedure in which a VBLM OFF(!) directive was active. You got it, guys -- see VBLM On/Off Toggling for details, and hats off for the idea!

String Extraction Pattern Testing

Walter Keutgen and Bob Greathouse both reported errors while extracting strings. I traced the problem back to their use of illegal patterns for pattern matching, basically unmatched square brackets. Walter suggested that it would be helpful to have VBLM do a validity check when patterns are entered, rather than erroring out during string extraction. Thus there is a new Test button on the SX option window, enabled when Pattern Matching is checked, that makes VBLM do just that.

LMX Import Logging and Help with Errors

At the suggestion of Juan Morales, VBLM can now write an import log recording the results of import operations (strings imported, duplicates, etc). Also, Mark Norton suggested that, since translators often screw up the LMX file format with extra or missing crlfs, it would be helpful to have VBLM track and report the last successfully imported line, to make errors that occur easier to find. VBLM now does this.

Property Stack Hacks

Property stack hacks? You probably didn't even know that you needed them, but VBLM now has 'em. Property stack hacks are a way of dealing with the arbitrary runtime property-setting syntax of certain controls, including some delivered in the box with VB (eg the listview). If you have VBLM build a runtime switched version of your app, and VB then complains about the property-setting syntax used in the VBLM_SetProperties event, a property stack hack can probably solve the problem. See Property Stack Hacks for details.

Bug Fixes

The following bugs, reported since the last release, are all fixed.

Walter Keutgen reported that although V4.0 claimed to have fixed the incorrect storage of the Extract Menu Shortcut option in VBLM.INI instead of in LMP files, it didn't seem fixed to him. He was right.

Someone (sorry, I forget who and can't find the original report) reported that when supplying fonts, VBLM would not supply a font to a frame that contained controls, but would supply a font to a frame that did not have controls.

Tony McSherry reported that VBLM failed to update the FRX offsets for TabPicture properties. In fact, VBLM failed to update FRX offsets for ANY subscripted property. Tony, sorry it took so long to fix.

Beth Kelley reported that the command line save switch did not work. It did most of the time, but not when certain other switches were used also.

Neil Newport, John Hoffman and Mark Dionne all reported that VBLM repeatedly crashed and burned during GetStrings, and was unable to complete when run against certain very large projects. With Neil's help, I figured out that the problem was caused by a) a control that had a very large number of string properties (eg Schedule.ocx, with more than 100), and b) VBLM's use of a 3D string array dim'd respectively by the number of control container files, the max number of controls in a file, and the max number of string properties on a control. When a large project combined with a control with a large number of properties, the string array was simply too big. As of Version 5, VBLM uses a 3D index array into a 1D string array, and handles large projects and controls like Schedule.ocx no problem.

Matt Baer helped figure out that VBLM didn't know about the ThreadingModel VBP key introduced with VB5 SP1 or SP2.

Juha Tenhunen reported that the length of Language.Dat file name was limited to 12 characters, a holdover from the short file name days. I discovered that a few other edit controls had the same problem (I'd obviously copied and pasted the file control, thus copying its MaxChars property).

Peter Durnin figured out that if a Friend function came first in a file, VBLM didn't replace its strings properly.

Ron Gordon pointed out that VBLM didn't handle related files properly. See Related File Handling for info on how it does now.

Ron also reported: "add Videosoft vsOcx6 Controls to a VB6 project. If one of the tabs does not contain any caption at all, the Caption property will include two vertical bar characters, one right after another. Example: "Tab&1||Tab&3". The actual caption for Tab2 is filled in at run-time. VBLM complains when building the multi-lingual project The string below has multiple translations..." I'm not sure this qualifies as a bug, but there is a work-around: open VBLM.INI with a text editor and change the value assigned to the MTSymbol key in the [General] section.

VBLM sometimes had problems storing files in directories named with extensions, and also had problems dealing with code modules that had no general declarations, ie the first line in the file was "Sub Foo (Yung as ChineseFood)"

Steve McRea reported that despite using the /NOSTOP switch, VBLM would stop and query about updating.

Martin Sperlich, Larry Gajdos, Bertrand Delaitre and Steve McRea all downloaded the V5 prerelease minutes after I uploaded it, and found some bugs while I wrapped up the help file.

Anything Else?

Sure, there's lots of little tweaks here and there. I don't remember all of them right now, but ones that I do include:

> Full UNC support

> At the suggestion of Larry Gajdos, VBLM now unprotects write-protected files after copying them (eg, *.frx).

> Project build options now store the names of only two RSV support files (the form and the module to use), instead of the full list of all files for all versions of VB.

> At the suggestion of Walter Keutgen, the LTE now displays the number of instances for each string, instead of just "Multiple Instances." Also, the topmost multiple instanced string on screen is labeled with a hint that you can see the full list by double clicking (this has always been the case, but a lot of users didn't realize it).

> New LMX file names now default to the name of the current name, not the name of the project.

That's about it. 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

Version 5.01

Version 5.01 ships at the beginning of July 1999, with fixes for the handful of bugs reported since the late April release of V5.00:

> Larry Gajdos and Beth Kelley pointed out that V5.00 was not preserving the RemoveUnusedControlInfo key in new VB6 vbp files. Fixed.

> Michel Luchmun reported that the V5 demo erroneously reported that it could only work with projects with 8 or fewer code files. Oops, this is the case for VBCP but not VBLM. The wrong message crept in when I moved to a common code base during V5 development. Fixed.

> Caroline Weston reported an Overflow error during BuildNewProject. The problem arose when controls named with large numbers (eg, Button3D7A) were passed to the routine that parses for (integer) subscripts to implement PropertyStackHacks. Fixed.

> Paul Berejnoi encountered errors and garbled output while printing. He had discovered a particularly embarrassing bug (in V3, fixed in V4, back in V5), whereby VBLM's failure to cope with the comma used as a decimal separator (common in Europe) was generating illegal zero values for margins and other settings. Wolfgang Rothhaupt and Michael Halevy also experienced problems related to this. Fixed.

> Richard Zeng and Paul Berejnoi reported "Control Array# does not exist" errors when loading the Build Options window. This was because they had their screens at low resolution and VBLM executed some un-updated resizing code left over from V4. Fixed.

> Steve McCrea reported a "File already open" error during an RSV build. It happened because a) he changed the name of Language.Dat, but b) built a resource version, which doesn't use Language.Dat. Fixed.

> Steve also reported that the file dialog for selecting the RSV support form supplied a BAS extension instead of FRM. Fixed.

> Martin Sperlich reported that changes made to the RSV user code prefix and suffix were not refreshed properly. Fixed.

> Bill Martin was about the 100th person to request that VBLM be able to point an LMP file at a VB project with a different name. Done.

> Dan Avni reported that both V5 and V4 created corrupt frm files when applying large but incomplete LMD files to projects, ie LMD files that did not have entries for the form(s) in question. Fixed (VBLM now leaves the original dimensions unchanged).

That's it. As always, many thanks and hats off to the people who took the time and trouble to report problems and help fix them!

Ben Whipple