VBLM uses an extensible scheme to encode the manner in which different controls store string properties in binary stash files.
This topic shows the details; see String Properties & Binary Stash files for an overview.
If you look in VBLM.INI, you'll see a section entitled [FRXStorageMethods] that looks like this:
[FRXStorageMethods]
VBCaption=0,4,0,0
VBText=0,3,0,0
VBList=1,2,0,2,0,1
CrescentEnum=1,2,1,1,0
MicrohelpEnum=1,4,0,1,3
Each named storage method is described by a list of numbers, at least 4 and possibly as many as 14
The first number encodes whether it is an enumerated (multiple-item) property. Thus VBCaption and VBText have 0, all others have 1.
The 2nd number is the number of bytes used to store numbers. Thus VBCaption uses long integers (4 bytes), VBList short integers (2). VBText is a special case; if the length of the text is <255 characters, VB uses a single byte to encode it; otherwise, it starts with chr$(255) followed by a short integer.
The 3rd number indicates whether the string data is null terminated (Crescent does this).
The 4th number indicates the number of additional entries that precede the length count and the actual string data, and the rest of the numbers encode what these entries mean:
0 = count of items
1 = longest item in list
2 = length of next item
3 = total bytes that follow
Thus when you see VBList=1,2,0,2,0,1, it tells you that, starting at 1+ the offset listed in the FRM file, a FRX file entry stored using this method will look like this:
2 byte integer: count of items that follow
2 byte integer: length of longest item that follows
For i=1 to Item Count
2 byte integer: length of string that follows
Property String
Next
Clear as mud, right?