QTreeWidget->clear() causing crash after sort

[Chuk]

I have a subclassed QTreeWidget that crashes the application when clear() is called after clicking a column header to change the sort order. It works repeatedly when the sort order is not changed, but once changed it crashes immediatly. On Windows, it gives exit code 3.

Anyone else experiencing this? I have no custom sorting of any kind, so I doubt it's my code, but could be.

-Chuk

[marcel]

It could be your code.
Can you post an example?

[Chuk]

There is quite a bit of code, as the subclass is for drag and drop. It would probably be easier to give a url to the project...

But, I found it was caused by the signal currentItemChanged(current, previous), or just the way I was using it. I only made reference to current, and a quick "if (current)" fixed the problem. But why would the current item be null in one sort order but not the other? Is this a Qt Bug?

[marcel]

I think the selection might be cleared when sort order changes.
Have you checked that?

[Chuk]

I have not checked in code, but visually, the same line is highlighted when sort order is changed.

I can see how as items are removed, the selected item could be cleared. But why would it be different between sort orders? It is only the Descending sort order that I get the null current item, with or without a selection. It seems like it should happen in both sort orders or neither.

[wysota]

Where exactly do you call clear()?

[Chuk]

Where exactly do you call clear()?

In a refresh() function in the QDialog that contains the Tree. It's called when the app loads to initially populate the tree, and is then connected to a button to refresh the list at any time.

Clearing the list and iterating through a plugin list seems the easiest way to refresh, rather than checking for additions or deletions.

[wysota]

When you clear the widget, all its items will become invalid, so if you store a pointer to one (or more) of them somewhere, you can't use it anymore - you have to ask the widget for the item again. Because you never know what caused a slot to trigger, you should always check for validity of pointers you get as slot parameters.