I put a sample app on my server at www.ExactChange.Info/TMSSample.rar . It’s not generating access violations but it does show that there is an issue nonetheless. Also included in this zip file is a short video that shows the program running into an issue.
The sample app creates a larger tree structure as it’s a little hard to test with the small sample tree; it creates 10 nodes which each have 10 children, which of which has 10 children and all the nodes have a random name.
There are two buttons which call the sort routine I’d posted on your forum. The only difference between the two buttons is that one calls ClearNodeList and the other does not.
One definite issue I’ve encountered is that ClearNodeList unselects the currently selected node and causes TreeView.SelectedNode to point at I-don’t-know-what. In the video you can see that when ClearNodeList is called, the currently selected node is unhighlighted. I believe this behavior is new as of the last update of the FNC UI pack, though I could not swear to that. Since SelectedNode is changed by the call to ClearNodeList, I had to make a slight change to the sort so that it’d store the node that’s being sorted (it was getting access violations because I was referencing SelectedNode but ClearNodeList was wiping out SelectedNode):
procedure TForm1.Sortsubseriesalphabetically1Click(Sender: TObject);
if (HoldNode.nodes.count>1) then
if (Sender=Button2) then TreeView1.ClearNodeList;
for y:=0 to (HoldNode.nodes.Count-1) do
for y:=0 to (ListBox1.Items.count-1) do
(This is probably obvious, but Instead of the Stringlist I used in the example of the forum, I used a tListbox just to make the list visible)
On a similar note, moving a node via drag-n-drop causes the SelectedNode to point at something else. In this sample app, if you select a node and drag to on to another node, you’ll notice that there’s no longer a selected node. That seems like new behavior, prior to the update it seems the node that was moved would remain selected, though again I can’t swear to that.
As you’ll see in the video, I sorted the children of the first node and everything was great. Then I sorted the children of the second node and things went haywire; the first node showed perhaps a hundred children suddenly and the tree’s indentation was totally screwy. I added a CollapseAll button to show that if the nodes are then all collaped, it seems to resolve the issue (until another sort is done).
Btw: I don’t want you to get the impression that I’m getting pissy; I really like your product but this does seem like something isn’t quite right there.
Gregg Van Oss
Wild Man Software