RSV: Enabling On The Fly Switching

By default, VBLM builds RSVs that begin execution by asking the user to select a language, then run in that language for the remainder of the session. However, VBLM also builds RSVs that can switch languages at any time during execution.

When the Enable On The Fly build option is checked, the resulting RSV has a VBLM_SwitchOnTheFly() procedure that can be called at anytime from anywhere in the project. When called, this procedure pops up the language selection list, then immediately updates all loaded forms with the new language. You need to decide where to insert these calls, as there are none to start with. At the end of this topic there's an example of using VBLM's compilation conditional option to help do so. VBLM takes care of the rest.

The VBLM_SwitchOnTheFly() procedure, which VBLM adds to the RSV support module, looks like this:

Sub VBLM_SwitchOnTheFly ()

Dim Junk As String, i As Integer 

Junk = VBLM_RTString(-1) 

On Error Resume Next 

For i = 1 To Forms.Count 

Forms(i-1).lblVBLMTrigger = " " 

Next 

On Error GoTo 0 

End Sub

How's it work? When VBLM_RTString() is called with -1 as the index argument, it pops the language list, reinitializes the database, and returns an empty string, so that takes care of that. Then the procedure loops through all loaded forms (using VB's Forms collection) and forces a language update by setting the lblVBLMTrigger controls' default properties (captions) to spaces. Huh???

All RSV form files with translated property strings have a VBLM_SetProperties() procedure that loads the proper language into these strings. This is called from the load event, so forms that are not loaded at the time of an on-the-fly switch will take care of themselves when they load. We do need to deal with loaded forms, however. We want to do so more elegantly than by unloading and then reloading them, but we can't call VBLM_SetProperties() from anywhere but the form code. Thus VBLM makes two additional modifications when it builds on-the-fly enabled RSV form files:

1) It adds a "trigger control" to the form, an invisible label named lblVBLMTrigger by default (you can change the name by editing the Trigger Control Name on the misc RSV build options node of the build window)..

2) It adds the following code as the trigger control's change event handler:

Sub lblVBLMTrigger_Change ()

Static Changing As Integer 

If Not Changing Then 

Changing = True 

VBLM_SetProperties 

lblVBLMTrigger = "" 

Changing = False 

End If 

End Sub

Thus when VBLM_SwitchOnTheFly() sets the caption to a space, this code calls VBLM_SetProperties() and resets the caption for the next call. The static Changing variable prevents a recursive cascade.

The only thing left to explain about VBLM_SwitchOnTheFly() is On Error Resume Next. The reason is that if there are forms in the project without translated property strings, they won't have VBLM_SetProperties() procedures or trigger controls either. Thus trying to pull the trigger is guaranteed to generate an error that we can safely trap and ignore.

Note: Labels can't be placed directly on an MDI form, so if your on-the-fly enabled project has one, VBLM will first create an invisible piclblVBLMTrigger picture box and place the label inside it. Picture boxes consume system resources, so if your MDI form already has one you're better off recreating the trigger inside it and deleting the picture box created by VBLM.

Using VBLM's Compilation Conditional to Implement On-The-Fly switching

VBLM's ability to add a "VBLM = -1" compiler conditional to the localized projects it creates can overcome the one annoyance in implementing on-the-fly switching. The annoyance is that, since you have to add the call (or calls) to VBLM_SwitchOnTheFly() yourself, these are your choices:

 You can add them to the localized project every time VBLM does a build. Since adding the call(s) probably involves adding some sort of interface element as well (eg, a menu item), this could be a major pain.

 You can add them to the original project but comment out the call to the non-existent VBLM_SwitchOnTheFly() routine, so the code will compile. Then you get to uncomment it in every VBLM build

 You add them to the original project along with a stub version of VBLM_SwitchOnTheFly(). Then you have to remove the stub from all new builds.

Moreover, in addition to the inconvenience, all of these choices prevent you from completely automating the build process, an important consideration for many users.

Conditional compilation, however, adds another, clearly superior choice:

 Add everything to the original project, but use conditional compilation to make it appear only in the versions built by VBLM.

For example:

1) Add mnuSwitchLanguages as a menu item to the desired form

2) In Form_Load(), add

#If VBLM then

 mnuSwitchLanguages.Visible = True

#Else

 mnuSwitchLanguages.Visible= False

#End If

3) Then add

#If VBLM then

Private Sub mnuSwitchLanguages_Click()

 VBLMSwitchOnTheFly

End Sub

#End If

Then just remember to check Add "VBLM=-1" compilation conditional to build on the Misc build options page, and you're in business.