Zugg Software :: View topic - [2.08] Tree view self-expanding

SubAdmin Joined: 18 Nov 2001 Posts: 5182

This still drives me nuts. Pratically from the first version where the Package Editor tree view didn't cause constant crashes it suddenly expands classes for no reason. I know not something to be worked on right now, but by far one of what I would consider the most irritating things.

A procedure to replicate this behavior
1. Launch CMud
2. Closes Sessions Window (ESC)
3. Enter at the command line

Wizard Joined: 17 Jun 2006 Posts: 1201

I can confirm this too. In fact, I posted about it a long time ago although don't ask me which version. I also agree it's very irritating.

Magician Joined: 09 Oct 2003 Posts: 459 Location: USA

I can confirm this as well. However, I can see what it is doing.

Before deleting the objects, I click on the XML tab to see the object properties. Note the ID of the object you're deleting.

I deleted one of the settings as instructed above with the ID of 1532. The class that contained the object with the ID of 1533 then opened. I reset and tried again. I deleted the object with the ID of 2570. The class containing the object with the ID of 2571 then opened. It's opening the class with the next ID number even though that has nothing to do with the action the user is doing.

2.08Pro (I double checked this time, Zugg)
Windows XP SP2

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Thank you Slicertool for tracking down that detail. It makes a lot more sense now why I needed to shove a random in there in order to find it. I am still trying to figure out the bug that lead me to develop this test, but I would be esctatic to get rid of this one along the way.

Just to be clear about what is really wanted here. I recognize that some setting has to be selected in the tree, although I still can't quite understand why. Don't even bother to imagine making a no setting selected view, it is just a waste of time. All anyone really wants is for no branches to expand unexpectedly, and a nearby setting to be selected. I think we can all live with anything that is 1 above or 1 below whatever was last selected, even if there is no way to understand how which of the 2 was chosen. The same applies to various move operations, dragging and right-click Move To. Currently moves cause the same sort of tree expansion that is irksome, it just adds too many steps to make a procedure based on them.

Posted: Wed Oct 24, 2007 5:24 am

A similar bug was a problem in zmud too. I have to second the statement that it is one of the most irritating behavioural glitches (hows that for a phrase :p) out there.

Posted: Fri Oct 26, 2007 3:37 am

Well, since I'm working on really annoying bugs today that weren't really high priority, I decided to mess with this one too. I guess I'm just really into torturing myself today or something.

Slicertool got this one exactly right. The TreeView is linked to the database. When you delete a record in the database, the database sets it's active record to the next physical record in the database. Obviously, the database doesn't have any idea how the TreeView is sorted and groups (nor should it).

Since the TreeView is synchronized with the database, when the database moves to the next record, the TreeView tries to focus it (by expanding whatever node it is in).

If you turn off the synchronization between the database and the TreeView, then when the database record is deleted, it doesn't get deleted within the TreeView (because it is no longer synchronized).

So, what I had to do was turn off the synchronization so that the intermediate class folders were not expanded, but then when the database record has been moved to the next record in the tree, I force the treeview to refresh itself. Even though this is a bit inefficient, it only needs to do it once after the deletion, no matter how many records were deleted. And even with a large number of settings, the delay isn't noticeable.

Anyway, I think it's working better now in 2.09. I really wasn't planning to work on this kind of minor visual stuff, but hopefully it makes the next version a bit more useable.

Posted: Fri Oct 26, 2007 3:39 am

Btw, this fix is only for the Delete operation. I don't have any fix for the Move commands at this point. They are *much* more complex than simply deleting a node, and I'd rather not risk data corruption just to fix some visual issue like this right now.

The way Move is currently designed is that it is supposed to keep the selected/moved node focused. So, if you move item A within class A into class B, then class B is going to be expanded and the new item A within class B will be the selected node after the move. The side effect that you might be talking about is that the original class A will still be expanded, because there is no way to tell the TreeView that you no longer want that branch expanded.