Understanding exported OleData

[HughWarrington]

Here's a section of a file called forms/Explorer.bas I recently produced using this fine Add-in to export a database I am working on:

Begin CustomControl
    Enabled = NotDefault
    SizeMode =1
    SpecialEffect =0
    OverlapFlags =93
    Left =285
    Top =390
    Width =6180
    Height =7140
    AutoActivate =1
    TabIndex =6
    Name ="Tree"
    OleData = Begin
        0x00180000d0cf11e0a1b11ae1000000000000000000000000000000003e000300 ,
        0xfeff090006000000000000000000000001000000000000000000000000100000 ,
        0x0800000001000000feffffff0000000001000000ffffffffffffffffffffffff ,
' ...
' many more lines of data hidden
' ...
    End
    OLEClass ="TreeCtrl"
    Class ="MSComctlLib.TreeCtrl.2"
End

The OleData continues for many lines.

Comparing exports for different versions of the .mdb I am working on, there is a lot of churn in the OleData here. I'm trying to understand what that means.

As far as I can tell, in Access OleData is a chunk of binary data stored in a particular format and accessed by the control's code in some way. In this case I strongly suspect it contains various icons used by the treeview. I would like to inspect the data and extract any images within, to see what the changes are between databases. There's a library for that here but it doesn't recognise the format of the above OleData. I performed the following clean-up steps to convert the above data into what I assumed would be the correct format for the tool:

1. Trim 0x from the start of each line.
2. Trim the comma from the end of each line.
3. Remove all whitespace.
4. Remove the newlines so the data is all on a single line.
5. Convert the data from hex to binary using Python bytes.fromhex().
6. Write binary data to file and try to open with olebrowse.exe from the above mentioned oletools.

I can't immediately see from the msaccess-vcs-addin source code where this OleData text comes from and what format it is in. I assumed it was MS OLE2 file format converted to hex and split across multiple lines, but that didn't work so I guess my assumption is wrong.

Does anyone know what format the OleData is in and how I can inspect it? Even being able to inspect the data inside Access would be a start, but I can't 'find' the data within Access either.

Any input would be much appreciated!

[hecon5]

What does this control look like? If you provide a screen shot, it may provide some clues.

I'm not familiar with how a treeview control works, but I imagine the OLE data is either the tree data, the icons in the tree, the dashes or delimiters, etc.

[HughWarrington]

Oh yes, it's absolutely a treeview (a rather ugly one at the moment). I agree with you, the OleData probably contains the tree icons, maybe the tree structure, or other settings.

My question is how do I parse/inspect this data? I thought 'where/how does the VCS addin get this data' might be a starting point.

[hecon5]

From my experience, that OLE export is just blob data; and Access has some format for each; why it changes after every (or seemingly every) export is likely due to parsing orders.

A similar symtom can be printers / screen colors changing the form colors when there's not a theme color set; this happens a fair bit, especially when two devs work on the same form but have different screen resolution / color settings. This is discussed a bit in #488, #183, #283, and a few others.

There's also PrtMip, which is largely standard, but #140 talks a bit about that.

Since I've never personally used TreeControls (they appear to be an ActiveX that's only available on 32bit machines best I can tell), and also don't have 32bit office, I can't be much help decoding, but I would perhaps consider instead using a different control type if you can. This one https://jkp-ads.com/articles/treeview.asp is apparently 100% VBA, which means it "shouldn't" change unless you actually change something. The other upside is it's not ActiveX, and works on both 32 and 64bit applications.

[HughWarrington]

Thank you for all the info.

This treeview control is definitely overdue for replacement by at least a decade.

I guess I will treat the OleData as an opaque blob and forget about it. On my current project for various reasons it has become less important to keep track of what those changes meant anyway. Just that there was a time in the code history when that form experienced a major refactoring, and then a constant low level churn at other times without any visible difference to the user.