This enhancement adds the ability to sync the vertical scroll operation between two parallel trees, one considered the master, the other the slave. When you drag the vertical scroll bar on the master, the slave tree is automatically scrolled along with it.
This probably only makes sense with property sheets where the items are logically parallel between the two trees, but have different data types. Otherwise, you'd probably just join the two trees since each column in a normal tree can have a different type.
To implement, plug the XTR.CTLNO (XTREE control number) of the slave tree, plus one, into the new XTR.SYNCCTLNO field in the XTRCTL structure. The +1 is required since zero is a valid control number, but it makes more sense to allow the default zero to indicate the feature is not being enabled. Assuming that you are using the typical auto-assignment technique for control numbers, by pre-initializing XTR.CTLNO to -1, this would require you to create the slave tree first (in order to get its assigned XTR.CTLNO) and then plug that in to the master tree's XTR.CTLNO.
The updated XTRCTL map and defstructs can be downloaded from the SOSLIB, but here is the what the tail end of the structure now looks like:
map2 FOOTERSTYLE,B,1 ! [138] same XTHSF_xxx flags as HEADERSTYLE (6.3.1537+)
map2 COLID,B,1 ! [140] column ID
map2 COLTYPEID,B,1 ! [141] column Type ID
map2 XDIRTY,B,1 ! [142] exit cell (XROW,XCOL) was changed (i.e. dirty)
map2 XDSPROW,B,4 ! [143] display row corresponding to physical XROW
map2 FILTERED,B,1 ! [143] =1 if rows have been filtered by user
map2 SYNCCTLNO,B,1 ! [144] XTR.CTLNO (+1) of XTREE ctl to sync scroll with
map2 UNUSED2,X,3 ! [144]
Note that despite the "master/slave" terminology, both trees are fully functional and independent, except for the fact that vertical scroll on the master is replicated to the slave and not the other way around. Also note that this mechanism isn't going to make a lot of sense for multi-level trees unless both are expanded/contracted in the same way. The master/slave mechanism is not currently extended to other tree operations besides scrolling; expand/contract and selection are not affected.
