The attached file is A2003 format and has been tested in A2003 through A2010 (32 bit). The TreeView control is not directly compatible with the 64 bit version of Access.

-------

The sample has a single form and single table. The table is a self-referential table in order to create the hierarchy of the TreeView object. Also, the structure of the table includes 2 fields (SectionIDPath and SectionPath) that are the stored result of a calculation. These two fields store the "full path" of the record with the SectionIDPath being a path using the id's (ie: 23\25\1) and the SectionName being a path using the names (ie: parent\child\grandchild). Yes, I know that is normally a bad idea to store a calculated result, however when dealing with hierarchical data and very large tables, the performance hit for calculating those values can be quite significant. So, in the end the two fields are not required for the TreeView in this sample to function, however, I do utilize the fact that they are there to improve performance. {Side note: with A2010, you can use a DataMacro to maintain these fields, which puts the responsibility on the dbengine as apposed to the application -- I will post a sample and link to it when I create one (IMG:style_emoticons/default/smile.gif) }.

The technique this sample uses is what I call the "optional double pass" technique to fully populate the TreeView. To build the TreeView, you pass in a SQL statement or recordset that contains all the nodes on your TreeView. If you have the "helper" field of the id path, you can sort by that field and make a single pass through the recordset to populate your TreeView. If you do not have the helper field, then you make a double pass of the records -- the first pass places all the nodes on the TreeView, the second pass positions all the nodes that are on the TreeView.

Another feature of this sample is Drag-n-Drop. To manage the hierarchy of the records, you simply drag the node you wish to change and drop it on the node it goes under (ie: similar to the file explorer in Windows). I have also implemented a ListView control that acts as a "Drop Zone". Its used when you can't see the destination node on the TreeView. To use the Drop Zone, simply drag-n-drop your node(s) on the Drop Zone, then scroll the TreeView so your destination node is visible, then Drag-n-Drop from the Drop Zone to your destination node.

Please note that other techniques of fully populating TreeViews exist, like a recursive call technique, but I found the optional double pass technique in this sample to be more efficient in my applications. Also, if the TreeView cannot (or should not) be fully populated in one shot (ie: HUGE hierarchical tables), there is a technique that I call "Lazy Loading" (aka: Load On Demand). That technique will load child nodes only upon node expansion. The Lazy Load technique is very efficient and can be utilized with the tree view code within the sample, but the search logic would change. I hope to post a sample of Lazy Loading in the future and link to it from here when that ocurrs.


I hope you find this sample useful. If you find any bugs, or see improvements that can be made, please don't hesitate to PM me here at UtterAccess.

I have to ask:

¿Is there a way in which it can be compatible?
Thanks in advance,
Diego

Hi Diego,

You can read through this thread for options, though unfortuantely, as of yet, there's no finalized solutions.