So you have selected a node, and have dragged it into its new position. But you don't want to move the node and all its sublists, its complete subtree. You want a full copy of the node and its subtree, at the new location, at the target node; actually just under the target node. So this would go right into the placeholder comment (in red) from the previous page.

The top node, the dragged/selected node, is copied to the underlying table. The difference is not only that the unique id number for the new record will differ from the original, but that this text label in the txCategory field is suffixed with some arbitrary text; " --1", in this example. That's to allow for the possibility that the target is in the same list, same level, as the selected node. There will be no confusion in that case, and one can simply rename the node after the copy is completed. Once copied, that unique id of the copy is read into, lngNewAnID, and the superior node of the selected/dragged node is placed in, lngOldSupID, by stripping away the leading letter with the Mid command.

So the simple copy is accomplished. One record has been copied. What about any and all sublists under it? Recursion might seem the obvious method. But it was felt there might be a lot of overhead with recursion, in this case. So looping was chosen instead. Recursion really is just a loop, but where variables at each iteration are saved invisibly by the system. To turn recursion into a simple loop, those differences at each iteration of the loop have to be logged or recorded somewhere. Here, a table, tblReCopy, is used to hold that information. There are really only two numbers that are of interest in this case. At each step, if that record has a sublist, you want the unique id of the original record. You also want the id of its superior node. And then you'll get back to these one by one, until there are no more.

Before beginning anything, the copy table is cleared from any previous use by the SQL "DELETE *" command. Now the table is empty. You find the entire sublist for the selected node, to begin with. You run through each record, making copies as you go. But each record itself is also checked to see if it has a sublist. If it does, then an entry is made in the copy table. The bookmark is here used to get back to the record just created as the copy, in order to get its unique generated id.

Then once the entire sublist has been copied, and any new entries made to the copy table, the copy table is examined to see if there remain any records; i.e. any sublists yet to scan. If so, that node now becomes the superior node, and the record in the copy table is deleted. And the loop continues in this way, with each new sublist. More entries are made to the copy table for each sublist yet to be explored, as the current sublist is copied in one shot. And as each new sublist is read back for the next iteration, that record is also deleted from the copy table. Eventually, the copy table will become empty, and the job will be completed. The entire original tree/subtree will have been copied, and the top node given a slightly different label/name.

But then what about the treeview? With all these new records, how difficult is it to update the treeview display? You can see there are a total of four lines at the bottom. A new node is added, with again the slightly modified text. It is sorted. It's superior node is sorted. And the 'fill-em-all' recursive routine is then used to fill out the entire subtree at once. That's it.

This was the 'free' Microsoft treeview control - if not free, then packaged with the rest of any Office kit, I believe. Again, graphics could be incorporated, but were not discussed, here. Neither was dropping to another treeview (which would just use the same dataobject class, mentioned previously, to read info on the node being dropped). And importantly, nothing was discussed about the use of sorting lists, manually, or by some method other than the built-in alphabetic sort of the text property. Such lists require an extra field in the table to hold the sort index. And one could move items up or down in a particular list, same level, and keep that ordering even if it's not alphabetical. It could be essential for laying out a web page, for example. But it requires a fair number of non-trivial routines to maintain this sorting, given the various operations one can perform on hierarchies via a treeview. Maybe, at some later date, then. [If one were curious, in the scheme used here, these simple alphabetical trees are later used to manually (typically) build a final tree which lays out the design of each web page, at least at the XML level. And those final lists are sorted, and use a sort field. So it doesn't matter if it isn't sorted, here. The sorting is done when the pages are built in this final treeview, which uses a different table.]

There are, however, any number of third-party commercial treeviews, as ActiveX or .NET or what have you. They are not necessarily inexpensive. But they might offer more bells and whistles, obviously graphics, faster loading, other options, what have you. It might be interesting to just run a Google (or whatever) search on, "treeview". And there are certainly a host of tutorials and webpages discussing treeviews, far more than just a few years ago. Again, a search of "treeview" will probably pick up more of those than commercial alternatives. Of course, as with anything Microsoft, these controls and routines are modified year by year and version by version. What tutorials you find for earlier treeviews, circa 1999/2000, and there are a fair number of pages discussing that version, may not entirely apply to this 'classic VB' version 6 control that was discussed here. And there would be .NET versions as well. So take care to note which treeview is under discussion, so that you won't be surprized at the presence or absence of properties and methods when time comes to try it yourself.

Unlike the treeview, which requires a lot of progamming support to get it to do most anything, the ActiveX web control doesn't require much more than a little set-up and knowing how to use it. The logic is all in the control. It's basically a little version of the Internet Explorer web browser, and uses presumeably the same routines as the fullon browser. So whatever page it loads, just as on the web, or locally on your hard drive, that's the page it displays. The real advantage of it, here, is that you can use it in edit mode. You can load up no page at all, basically, and just load in some text, and edit it. There are seemingly an unlimited number of undo levels. You have the same text search as with a web page. If the text is there, it will be highlighted. The markup will all be HTML, and ready to go out to the web page you are building. There are only a couple of things to watch for in editing, saving, etc, noted further on.

Prior to the use of this web control, a lot of people wanted to mark up their plain text, say with bold, italic, colored text, etc, and then save the result in a field for later retrieval. But they used another control - the RTF control. It was better than just the plain text of a text box. It's the same RTF markup format that once was used with the old Windows Help compiler. There were a lot of limits to such a control, however, compared with an editable web browser control. For so many reasons, a few touched on above, the web browser control is easily the better choice, particularly if you intend to compile various data into a web page. There are a number of built in keyboard commands, undo levels, output is already HTML, etc, etc.

Under the Insert, ActiveX Control, you'll want to select the - Microsoft Web Browser. The class might read - Shell.Explorer.2 . And it does require some initialization.

Continue