Keeping a single level of a TreeView sorted

[MarkMLl]

What is recommended practice for keeping a single level (level 1 out of 0-1-2) of a TreeView which is getting a lot of program-driven updates (add-move-delete plus text changes at levels 1 and 2) sorted?

The user won't be changing anything but might be expanding/shrinking level 0 and 1 nodes to see their content.

At some point the selected node might be significant, to mark that detail be displayed elsewhere in the window.

MarkMLl

[jamie]

I think you should be building those nodes off the side then do a complete update of said nodes while blocking the user in the process.

I found things don't go well when user is interacting with the treeview at times while background updates to the nodes are taking place.

[cdbc]

Hi
I'm doing my inserts into the tree sorted by/in code, no direct interaction from the user. (S)He can choose, collapse & expand nodes, but for addition & deletion (s)he gets an 'inputbox' or 'messagedlg' and I do the insertion or deletion in code.
At the same time I'm also employing @jamie's technique... sort of beginupdate/endupdate style...
Regards Benny

[MarkMLl]

Yes, that's pretty much what I'm doing. The TreeView is there to display to the user, not as a primary means of data entry or manipulation.

MarkMLl

[cdbc]

Hi
Yeah Mark, that's exactly my view on the matter too...
Plus, I haven't yet come around to familiarize myself with this 'Virtual mode'...
Regards Benny

[MarkMLl]

I've been wrestling with interactions over the last few days, but think I've got things sorted by now. Incoming contact blips, a callback to code to add/move/update/delete traffic slips in a TreeView, depending on what happens there the blip is either added to a cache or used to update an existing entry.

The tricky bit centres around a CustomDraw to handle colours, since that relies on a TreeNode.Data pointer to a blip... so it's vitally important to know whether it's been cached or deleted (which would of course be a serious error).

Central to that is being absolutely sure that all TreeView operations have, in fact, been completed before cases where a blip is copied into an existing cache entry and deleted. I'm not sure whether there is a simple "MessageQueue is non-empty" test, but I might add an extra IdleTimer which does nothing but update an activity counter indicating that no further APMs are needed.

I'm still interested in anybody's thoughts on single-level node sorting, but meanwhile am moving on to displaying map overlays using a facility that Alpine has recently added to LazMapViewer.

MarkMLl