As of Version 5, VBLM can localize VB project files created by ActiveX designers (*.dsr). Designers, introduced but left virtually undocumented in VB5; are central to VB6's new feature set. Designers are top-level software components that have a programmable interface and a dedicated visual design environment. Because of their power and flexibility -- for example, designers may or may not have a visible runtime interface -- and because of the wide variety of third party products that are already appearing (remember the old VBX days!), designers pose a considerable challenge to the kind of systematic processing and regeneration that VBLM needs to perform.

In fact, it is impossible to process and regenerate designers the same way that VBLM handles all other VB file types -- that is, to treat them all the same way -- because different kinds of designers use property strings in different ways and demand different approaches to processing them (embedded strings in a designer's procedures, on the other hand, can be handled the same way as those in the procedures of any file type). Before VBLM can localize designer files of a given type, therefore, it needs to be configured to handle the property strings correctly.

VBLM comes pre-configured for the designers that ship with VB6, as shown in the window pictured below. This window pops up when you select Designer Files on the options menu, and can be used to add, edit, or review VBLM's designer list.:

image\DSR1.gif

When VBLM encounters a designer in your project that it does not yet know about, it will pop the following window for you to use to instruct VBLM how to handle its property strings:

image\DSR2.gif

Class Name

The class name for the designer will be filled in for you, unless the designer is not properly registered on the computer running VBLM. If VBLM can't find the designer in the registry, the designer's GUID will be displayed instead and you should manually enter the class name.

Extract and Replace Strings...

Does this designer type have any strings in its definition section that should be localized? If so, like the DataReport designer, check the box. If not, like the DataEnvironment designer, do not check the box. If the box is not checked, VBLM will ignore the definition section of the designer (although it will extract strings embedded in the procedures). If the box is checked, VBLM will extract property strings from the definition section. The manner in which it does so is controlled by the next setting.

Use the Following List

The Use the Following List... checkbox represents a fundamental departure in the way VBLM has always worked, which is to extract all strings unless a string extraction rule instructs it not to. If this box is not checked, VBLM will handle this designer's property strings the same way, extracting them unless a rule tells it not to. However, if this box is checked, VBLM will only extract property strings from properties listed below. I implemented this option because, at least among the designers supplied with VB6, it appeared that a) they have lots of string properties, and b) practically none of these properties are part of a visible interface.

Properties to Extract and Replace

Use this pseudo listbox to enter the properties that you want localized when the Use the List box is checked.

Initialization Event

When VBLM is configured to build runtime switched versions of your apps, it adds initialization code to all files with visible interfaces. It does so by adding a VBLM_SetProperties procedure, and inserts a call to this in a startup event; in forms, for example, in the Form_Load event. The default startup event for designers is the Initialize event, but you can change this if necessary by editing this entry.