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. 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.
When VBLM constructs VBLM_SetProperties events, it generates code that sets string property values at runtime. It figures the syntax to use from the way the property is laid out in the definition section of the control containing file;. For example, this is how a label control is laid out in a form definition:
Begin VB.Label MyLabel
Caption = "This is MyLabel(1)"
...
End
and this is the code that VBLM generates to set the caption at runtime:
MyLabel(1).Caption = VBLM_RTString(SC_269)
VBLM knows how to write this code because when it read the definition section and extracted the caption, it had been keeping track of "Begin..." statements and indexes, and stored the results; when it writes the runtime code, it basically plays them back, adding indices and separating the tokens with dots. The scheme works fine as long as the runtime code resembles this "property stack" stored in the lmp file, and in fact has continued to work fine even as controls and properties have become far more nested and complex. Some current properties are properties of properties of properties, and the runtime code is
ControlName.Property1.SubProperty2.SubSubProperty3 = VBLM_RTString(SC_201)
Now, however, consider the ColumnHeader.Text property of the ListView control that ships with VB. It lays out like this in a definition:
Begin ComctlLib.ListView MyListView
BeginProperty ColumnHeader(1) {0713E8C7-850A-101B-AFC0-4210102A8DA7}
Text = "Description"
...
EndProperty
End
The problem is that after VBLM reconstructs the code as
MyListView.ColumnHeader(1).Text = VBLM_RTString(SC_103)
VB will complain and refuse to compile, because the correct syntax for setting the text property is
MyListView.ColumnHeaders(1).Text = VBLM_RTString(SC_103)
Somewhere along the line, somebody decided that the runtime code should use the plural "ColumnHeaders" instead of "ColumnHeader" as it's laid out in the definition. This is what I mean by ARBITRARY! And the problem is even worse in the DataReport designer shipped with VB6, where in addition to wording differences ("Controls(x)" instead of "Itemx"), the definition section uses 0-based indices but the runtime code uses 1-based indices. Geez, guys, you really can't do better than that? How is VBLM supposed to cope with this nonsense?
The answer (of course) is property stack hacking, a way I concocted to document and work around this arbitrariness one problem at a time. If you look in the VBLM.INI file, you'll see the following section and entries:
[PropertyStackHacks]
Hack1=ColumnHeader(#)|ColumnHeaders(#)|ListView
Hack2=Section#.Item#|Sections(#+1).Controls(#+1)
A property stack hack consists of at least two and sometimes three parts, all separated by a bar (chr$ 124, the pipe character):
Part 1 is the syntax indicated by the
way the property is laid out in the definition section, ie
the way VBLM is going to construct the code using its standard method,
though with "#" as the placeholder(s) for any index subscripts,
substituted sequentially left to right.
Part 2 is the correct syntax, ie the way you need to code it to avoid
errors, again using "#" as the placeholder(s) for any index
subscripts.
Part 3, optional, is the control class.
If specified, VBLM will only convert Part 1 syntax to Part 2 syntax when
the property in question belongs to a control of this class. If not specified,
VBLM will convert any instance of Part 1 syntax to Part 2 syntax.
In action, then, after creating but before writing each line of property setting code in VBLM_SetProperties events, VBLM compares each left side to all defined hacks, and substitutes accordingly. Ugly yes, but it works like a charm.
The 2 hacks shown are installed by default and take care of the problems I know about with the stuff that ships in the VB box. However, it's quite likely that there's more arbitrariness already out there and more to come, which is why I implemented property stack hacks as a user-definable capability. VBLM doesn't have a fancy editor or interface for defining hacks, but all you need is a text editor, VBLM.INI, a sample form definition section, and knowledge of the correct runtime property-setting code. If you can't figure it out, email tech support and we'll see what we can do.
Note: When adding hacks, be sure to number sequentially, ie Hack1, Hack 2, Hack 3, and so forth. When reading in hacks, VBLM counts up from 1and quits at the first missing number.