What happens after closing and before destruction?

[Raccoon29]

I'm trying to reproduce the error in a minimal application as you suggested, but still the problem has not shown itself.
I attached the source of the minimal application, maybe in the meanwhile some one of you could make the error raise, playing around...

[wysota]

If it works fine then try to isolate some other part of your code and implement or paste it into the test environment you just built.

[Raccoon29]

If it works fine then try to isolate some other part of your code and implement or paste it into the test environment you just built.

Ok, I'm trying it.

Meanwhile, do you have any sort of idea of what is this dued to? Or do you have any idea on why the focus should heal it, what sort of signals could emit the focus?

[wysota]

If I had, I would have already told you.

[mchara]

Hi,
I'm using Qt::WA_DeleteOnClose with MDI sub windows and it works fine, so i think it's some bug in your code(not qt's).
Qt docs says that mdi sub window should have set Qt::WA_DeleteOnClose because QMdiArea won't work properly.

When you create your own subwindow, you must set the Qt::WA_DeleteOnClose widget attribute if you want the window to be deleted when closed in the MDI area. If not, the window will be hidden and the MDI area will not activate the next subwindow.

However i think it may be a problem with Qt::WA_DeleteOnClose defined twice - on QMdiSubWindow itself and on widget contained by this QMdiSubWindow.
This could produce a crash because hiding subwindow deletes subwindow & contained widget & then widget is removed once again.

I'm not sure about this, but if QMdiSubWindow have Qt::WA_DeleteOnClose attribute set(and it probably have set it by default), you shouldn't set it on widget of sub window.

[wysota]

I'm not sure about this, but if QMdiSubWindow have Qt::WA_DeleteOnClose attribute set(and it probably have set it by default), you shouldn't set it on widget of sub window.

If the widget is not deleted explicitely in the destructor by calling delete on it, it shouldn't be a problem - QObject will "disconnect" the object from the list of its children so it shouldn't be deleted again by the parent as it has no parent anymore.

[mchara]

If parent is removed after child - you're right,
but if parent is removed first(and removes child) and then child is removed explicitly, then we have wrong pointer there.
And what if both generate deleteLater events on hide?
Is it managed on the level of event loop?
If hide event is called on parent, it calls hide on child, and both generates deleteLater events,
so if then delete event of parent would be processed (and delete also child), child's delete event is already queued...


One more thing worth a check is creating widget normally embedded in mdi sub window without it (just create & show standalone) and delete it (via delete, deleteLater or close with DeleteOnClose attrib) and see if problem isn't inside of that widget.

By the way wysota,
Great article about undo/redo framework in qt quarterly

[wysota]

but if parent is removed first(and removes child) and then child is removed explicitly,

It is not removed explicitly. By explicit I mean that you delete it manually instead of letting Qt handle that.

then we have wrong pointer there.

No.

#include <QApplication>
#include <QWidget>
 
 
int main(int argc, char **argv){
  QApplication app(argc, argv);
  QWidget *parent = new QWidget(0);
  parent->setAttribute(Qt::WA_DeleteOnClose);
  QWidget *chld = new QWidget(parent);
  chld->setAttribute(Qt::WA_DeleteOnClose);
  parent->show();
  return app.exec();
}

#include <QApplication>
#include <QWidget>


int main(int argc, char **argv){
  QApplication app(argc, argv);
  QWidget *parent = new QWidget(0);
  parent->setAttribute(Qt::WA_DeleteOnClose);
  QWidget *chld = new QWidget(parent);
  chld->setAttribute(Qt::WA_DeleteOnClose);
  parent->show();
  return app.exec();
}

To copy to clipboard, switch view to plain text mode 

The above code works just fine.

And what if both generate deleteLater events on hide?

That's exactly what happens with the attribute set.

Is it managed on the level of event loop?

Yes, the event loop handles that.

If hide event is called on parent, it calls hide on child, and both generates deleteLater events,
so if then delete event of parent would be processed (and delete also child), child's delete event is already queued...

But it doesn't get executed. When an object is deleted, pending events are discarded (that's not exactly what happens, but the result is valid).

By the way wysota,
Great article about undo/redo framework in qt quarterly

Thanks. It looked much worse before they corrected the language

[Raccoon29]

Thank you for your ideas so far, please keep it up

New clue: if I always ignore the closeEvent of Manager (the third bastard window), the window keeps opened, but the problem disappears. Anyway this is just a dodge, I have to find the reason.

One more thing worth a check is creating widget normally embedded in mdi sub window without it (just create & show standalone) and delete it (via delete, deleteLater or close with DeleteOnClose attrib) and see if problem isn't inside of that widget.

Great idea this one! I didn't try it.
I'll try it, then I'll report how it goes.

[Raccoon29]

I tried two tests:
1) make the Manager a simple dialog not MDI
2) set in the MdiSubWindow a Manager created at the moment of adding
results:
1_ Manager isn't of course in the MdiArea anymore, but no error there, everything works fine
2_ For compatibility reasons it wasn't a precise try, but anyway I really think that this won't be usefull

I'm going to try a neutre widget in the MdiSubWindow (not Manager, but a simple QWidget) to see if is a Manager internal code bug, might this be usefull?

Useless to say that every idea or possible clue are still much apprecciated

EDIT: @mchara if your idea is not between the tryies I did, please tell me, it would be an added test

[mchara]

Both tests should tell us where to search for a bug i think,
or at least exclude some potential reasons of a crash.

So...
let us know about results of second test and i hope it will give us some new clues.

[Raccoon29]

I tried the neutre QWidget, but the problem persists.
Is it possible that setFocus() for widgets has a point of "abuse"?
I ask this because during the tests I found another Qt assertion failed that fixed when I removed a couple of setFocus(). So, since the problem disappears when making the program window lose the focus (that focus trick), I was wonderign if this two behaviors can be correlated?
Can Mdi have some weak point when using (or even abusing) setFocus method?