Revision History: What's New in Version 2?
In a word? Lots!
In 25 words or less? Almost every new feature and enhancement that VBLM1 users requested, plus more that we thought of ourselves.
In 1,000 words? Well, here's the highlights...
The string extraction options have been dramatically expanded and refined to give users much more control over the string extraction process. More specifically, you can configure VBLM2 to systematically exclude almost all strings that shouldn't be translated: See string extraction overview and configuring SX options.
VBLM2 also has new features to help you configure the expanded (and more complex) SX options: See Tips & Tricks.
And there's a new extraction engine under the hood. You may not notice on small VB projects, but if you cross the ~2,000 string threshold you most certainly will: it runs about 100 times faster.
The Language Table Editor
We received many compliments and few complaints about the LTE in version 1, so it has been refined but not dramatically changed in version 2. The two most significant changes are the ability to "delete" unwanted strings from language tables, and to override single-instancing.
Despite your best efforts with the SX options, a few unwanted strings always sneak through and end up on the language table. VBLM2 allows you to essentially delete them, but without having to redo the deletions after every update: For details, see Marking Strings as Excluded.
VBLM's single-instancing feature (it only extracts one copy of a string, regardless of how many times it exists in the project) proved to be an occasional curse as well as a general blessing in VBLM1. Most users were delighted that they only had to translate things once, and it worked as intended 95% of the time. The other 5% was a bugger, though, because when users wanted to translate the same string differently in different instances, or to translate one instance and not another, they were out of luck: single-instancing could not be turned off. VBLM2 preserves the benefits, but also allows you to override single instancing when you need to.
Other new features include access to SX options, export options that quote strings and remove ampersands, and an improved keyboard handler that no longer intercepts system keystrokes and lets you scroll the context window without losing your place in the Multiple Object list.
You will see many new options on the Build Options window, particularly if you've got VBLM. Both editions have the new Apply Extraction Options feature for intelligent string replacement, the ability to ignore parts of original source (including entire files), and the ability to log all build changes to disk. In VBLM, though, there are so many spiffy new build options that they're split into 3 groups:
New RSV build options allow you to create user-editable ANSI Text language databases, retain replaced strings as comments, support on-the-fly language switching, and more. See RSV overview, RSV Build Options, and Enabling On-The-Fly Language Switching for info.
VBLM's entirely new Dimensioning options keep you from having to do the same work twice. It's a near-certainty that you're going to have to fiddle around with interface dimensions to get a translated version of your app to look as good as it does in the design language. VBLM2 won't do this for you, but it preserves your work across builds. See dimensioning overview and dimensioning options for info.
VBLM's Supply Missing Font build options, also completely new, alleviate major tedium that VB imposes on localizers when they're translating into languages that use different character sets. See Translating Across Character Sets and Supply Missing Font Options for details.
No, we're still not in the manual business, but we've nearly doubled the contents of the online help. Almost all topics have been rewritten and expanded, many new topics have been inserted, and we have added numerous overviews of complex topics.
VBLM1 users asked for many new features but reported few serious bugs. We didn't find too many either in our customary continuous testing. That said, here's the list:
The following bugs, roughly in order of decreasing seriousness, were found in VBLM1 and fixed in VBLM2. The number in parens is the number of times each was reported, with 0 meaning never: we found it ourselves.
> If you didn't include the design language when building an RSV, the RSV didn't work AT ALL because V1 didn't insert the number of records at the top of the language database (1, 6 months after release, and I still can't believe it. Wow!)
> When run against large VB projects with thousands of strings, V1 slowed to a crawl during extraction when the string count passed 2,500, and sometimes had memory leaks and string space errors. V2 sprints regardless of project size, nor does it leak or run out of string space (3).
> If a given string occurred many (hundreds) of times in a project, the LTE could generate an overflow error followed by an out of string space error (1).
> When the LTE was set for Column format, V1 could botch saving column widths and generate an overflow error the next time the LTE was opened (1).
> V1 would not extract a string from a line of code if it directly followed another string that had a period in it (1).
> Under certain circumstances when a string had a period in it, V1 would extract only what fell to the right of the period (0).
> When a token in a line of code matched a token on the Excluded Properties list, a string directly to the right of the token would not be extracted, even if there was no equal sign in between designating assignment (1).
> If you overrode default filenames in dialog boxes, V1 inserted 2 periods between the filename and the extension and generated a bad file name error (1).
> Pasting from the clipboard in the LTE didn't fire the dirty flag in V1, so the inserted text didn't "take" unless you also hit a keystroke (2).
> V1 wouldn't recognize an empty root directory (ie no subdirs or files, typically a ramdrive) as a directory (1).
> V1's LTE keyboard handler intercepted Alt-Tab and prevented task switching (1).
> Bug or just lousy interface design? Several users generated errors by attempting to File/Open VB projects instead of VBLM projects. This has been fixed by taking all but the relevant file specs out of the dialog boxes and advising users who attempt to open MAK files (4).
As always, my apologies and thanks to the users who discovered these problems and took the time and trouble to help me figure them out.
Welcome to VBLM Version 2!
VB Language Manager Version 2.11 shipped on August 15, 1995 with fixes for 5 obscure bugs. See Bug Fixes in Version 2.11 for a description.
VB Language Manager Version 2.10 shipped on July 14, 1995. Version 2.1 is primarily a maintenance release with fixes for all known problems in Version 2.0. However, we couldn't resist a few new features and design changes to reflect what we've learned from customers in the 4 months since V2.0 shipped.
NEW FEATURES & DESIGN CHANGES
Many users were puzzled by V2.0's queries about string extraction (SX) option changes when they performed a project update. The puzzling queries were a reflection of the way that V2.0 stored SX options, which was itself a bit puzzling. This has been restructured and improved: see How SX Options are Stored for more info.
Some users wanted to extract strings only from form definitions, not from code. V2.1 offers this capability with the VBLM OFF! feature. See VBLM OFF/ON Toggling for details.
V2.1 allows you to have periods in all SX option tokens (eg "debug.print" works as you would expect), and to have "spaces" in the SX option pattern masks; see SX Options: String Patterns.
Language Table Editor (LTE)
The big change in the LTE is the new code window. Whereas V2.0 displayed the single line of code from which a selected string had been extracted, the code window displays both the line and up to 32K of the surrounding code. See The Code Window for info.
Before performing an import, the LTE now queries if you would like to scan incoming strings for errant control characters, and remove them. This solves the problems caused when import files are imperfectly converted to TXT format by translators' word processing applications.
If you have given a string multiple translations (see overriding single instancing), when you are asked during the build to select translations for individual instances, V2.1 allows you to pop up the Code Window and view the surrounding source.
V2.1 has a new RSV build option that allows you to control whether or not VBLM nulls translated property strings in the form definitions it creates (V2.0 always erased them). See RSV Code Modifications for more info.
When VBLM creates a new project, it stores the full paths of all VB project files in the VBLM project file, and expects these files to remain in the same place. When users later moved their VB projects into different directories, VBLM 2.0 was thus unable to find them. When VBLM 2.1 does not find the parent VB project in the original directory, it allows you to look for the project in a different directory.
BUG FIXES IN V2.1
String Extraction & Updating
The biggest source of problems in V2.0 was the Update procedure, which was flawed enough to be embarrassing. When V2.0 users ran an update, files marked as excluded were NOT excluded, and VBLM OFF/ON toggling was ignored, regardless of the option setting. Also, user-defined types with elements named "Sub" or "Function" caused "Input past end of file" errors during an update, though not during initial extraction. Finally, the update procedure could generate "subscript out of range errors" if the VB project contained more files at the time of update than it did initially. Whew!
The fundamental problem was that V2.0 had separate routines for initial string extraction and update string extraction, which I failed to keep synchronized. V2.1 fixes both the symptomatic errors just described and the fundamental problem: it now uses the same routine for both extraction steps.
Language Table Editor
On large language tables, certain combinations of table entries and sort keys caused V2.0's quicksort procedure to exhaust VB's stack and fail with an "Out of stack space" error. The problem is unavoidable (the sort algorithm was not flawed, VB's small stack just can't handle the depth of recursion needed to complete some sorts). V2.1 still attempts to quicksort first. If quicksort fails, however, instead of giving up as V2.0 did, V2.1 shifts to a slower but more reliable exchange sort and continues.
Two minor sort changes: When sorting by filename, V2.0 sorted on the parens it inserted; V2.1 does not. Also, V2.0's sort window allowed you to specify illegal nested sorts (eg, a 2nd level sort without specifying a 1st level sort). V2.1 does not.
Users who made changes to Windows' international settings (in particular, the list separator and decimal characters) and then restarted VBLM 2.0 were plagued with errors when they opened the LTE: "Invalid Property in frmLTE!SetFonts," etc. The problems were caused by entries in the INI file that were written using one international format, then read using another. V2.1 solves this problem by retaining the settings used to last write the file in the file itself, and uses them to read it.
Note: If you are upgrading from V2.0 and have changed the international settings, this modification may cause similar errors the first time you start up VBLM 2.1. To fix the problem, delete either the entire INI file or, less drastically but more work, those entries in the INI file that use the affected characters. This includes *Font, *Win, and a few others.
In V2.0, pasting single translations from 3rd party translation apps via Edit/Translate/Paste did not fire the dirty flag, and thus the translations were not saved unless the user also hit a keystroke. Fixed.
After performing an import, the LTE in V2.0 did not refresh the display of the currently selected item. Fixed.
When printing language tables with a bold font, V2.0 failed to bold the first item. Fixed.
VBLM Pro 2.0's width checking did not function properly when container forms' ScaleMode property was set to anything other than twips. The mistaken assumption that dimensions were stored in the form file in ScaleMode units (as they appear in the properties window on-screen) has been corrected, and V2.1's width-checking now works fine whatever the ScaleMode.
During a V2.0 width check, extremely long strings could generate overflow errors. Fixed.
When strings have been multiply translated, VBLM pops up a selection list when they are encountered during builds. Due to an indexing error, V2.0 always treated the second-to-last item on the list as "Don't Translate." V2.1 translates properly.
RSV Only: If 1) you translated global string constants, and 2) one or more files in the VB project had NO strings but DID reference the string constants, then 3) V2.0 did NOT replace the references in these files with function calls, as it should. V2.1 does.
Dimension Preservation: V2.0 failed to find and apply dimension data that was offset more than 64K from the beginning of dimension data (*.LMD) files. The problem was that V2.0 used the WinAPI GetPrivateProfileString function to retrieve the data, which apparently has this (undocumented) 64K limit. V2.1 does not use this function and can read and write LMD files of any size.
The Tech Support item on V2.0's Help menus did not bring up the Tech Support topic. Fixed.
If you canceled the operation of creating a new project, V2.0 left the dirty flag set and a few other variables with improper values. Fixed.
That's about it. As always, sorry for the bugs and many thanks to the users who took the time and trouble to help me figure them out and get them fixed. Welcome to VB Language Manager Version 2.1!
Geez, wouldn't you know it! As soon as I got V2.10 out the door in July, industrious users uncovered 5 obscure bugs, some dating back to V1 and none caused by the changes in 2.10. Anyway, they're all fixed as of 8/15/95.
Shuk Chan reported that some strings assigned to constants that were on the Don't Extract Strings Assigned to These Identifiers list were being extracted regardless. The problem turned out to be constant names that contained the string in its entirety; when VBLM encountered an assignment like this:
constLanguage = "Language"
it would extract "Language" even when constLanguage was on the list. Fixed.
Language Table Editor
John Motycka found that after repeated searches in the LTE, the vertical scroll bar ceased working. Yup, turns out that a flag set to prevent recursive cascades in the scroll event was not being reset. Fixed.
Shuk Chan also found that constants in certain form files weren't being translated during an RSV build. I traced the problem to the Type property of Desaware's sbc control in the form definitions: VBLM encountered it during a final constant replacement pass, decided it started a type definition, and stopped searching until it found the end (which it never did). Fixed.
Stephen Jackson and Marcos Garcia reported that, although every file in their VB project was saved as text, VBLM a) insisted on starting VB and loading it for conversion, and b) when it was done, there were a bunch of 0-length vbx files in the project directory. It took over a month for me to replicate this problem, but it turned out to have a simple cause and fix. The problem only occurred if VBX files were not in the project, Windows, or System directory. VBLM could not find them (not a problem), but then failed to flag them internally as vbx files. This was a big problem because it then treated them as binary modules. Fixed.
AT LAST! Every once in a while, users have reported an overflow error in the main form's Bounce routine. This was a totally trivial problem, but I could never replicate it and it drove me crazy. Finally found and fixed!
As always, my apologies for the bugs and my thanks to the users who took the time and trouble to help me figure them out. Particular thanks to Shuk Chan, who's been torturing VBLM to the best of her abilities.
Complete Revision History