What happens after closing and before destruction?

[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?

[wysota]

I'd really suggest looking for the problem in your code and not Qt.

[mchara]

Can Mdi have some weak point when using (or even abusing) setFocus method?

I think not,
Your MDI manager might have some...
Tests you performed suggests that error is in your code - if child widget works if it's not in mdi area and empty widget placed in mdi area causes a crash the problem is surely somewhere in MDIArea subclass implementation or on it's communication with the rest of application.

If you have problems with setFocus() used in your code you should check if pointers are valid everywhere.

If it still doesn't gives you a clue, try to trace call stack (when debugging after a crash) - it should show a method where you're doing something wrong.
Or if call stack doesn't says anything useful, it's usually some slot executed by a signal emition.

[Raccoon29]

I'd really suggest looking for the problem in your code and not Qt.

I know the problem is in my code, it must be there.
But to know what part of my logic is wrong, I have first to understand why the problem raises, and since the problem is a Qt library assert fail, I have to understand for what reasons that assert fails. It fails because MDIsubwindow indexes are out of range. Great. But I never touch Mdisubwindow indexes (that's Qt stuff), so the problem begins even further!
I'm sure that Qt is stable enhough to resist to newbies attacks too.

[Raccoon29]

If it still doesn't gives you a clue, try to trace call stack (when debugging after a crash) - it should show a method where you're doing something wrong.
Or if call stack doesn't says anything useful, it's usually some slot executed by a signal emition.

The trace just says me that the close method begins everything, but that was known.
Maybe I have found a clue, but I need to ask you a question:
when the control is in the Widget contained by the MdiSubWindow, what would be the best way to close the subwindow programmaticaly?

I mean, by now when I have to close the window after an operation is complete, I do:

void frmmanager::close()
{
    viewport->close(Manager);         //  just nullifies Manager pointers
    viewport->getMDI(this)->close(); // calls the close of the MdiSubWindow
}

void frmmanager::close()
{
    viewport->close(Manager);         //  just nullifies Manager pointers
    viewport->getMDI(this)->close(); // calls the close of the MdiSubWindow
}

To copy to clipboard, switch view to plain text mode 

where viewport is a my class that manages subwindows' pointers, and getMDI returns the pointer of the Mdi that contains the widget I pass it (like QMdiSubWindow::widget(), but reversed).
The target is to close the MdiSubWindow, because if I call the Widget's close, the QWidget closes, but its MdiSubWindow keeps opened (empty but opened).

Is this a self-destructive way to close it? Maybe there is a better way to achieve that?

[mchara]

I think you shouldn't close subewindows at all when main window closes. Qt surely propagates close events to widgets children in a background.


And one more thing that can be a reason - when you are overriding events always remember to call ancestor method i.e.:

void frmmanager::close()
      {
          QMainWindow::close();// OR WHATEVER frmmanager INHERITS
 
          viewport->close(Manager);         //  just nullifies Manager pointers
          viewport->getMDI(this)->close(); // calls the close of the MdiSubWindow
      }

void frmmanager::close()
      {
          QMainWindow::close();// OR WHATEVER frmmanager INHERITS

          viewport->close(Manager);         //  just nullifies Manager pointers
          viewport->getMDI(this)->close(); // calls the close of the MdiSubWindow
      }

To copy to clipboard, switch view to plain text mode 

Qt may do something important in those events, so if you're not calling ancestors events you may cause qt's internal implementations works wrong.

It's not always a problem cause there's lots of events that does nothing and are meant only to us to override them, but not always it is so.

BTW: sorry for late response.

[Raccoon29]

I think you shouldn't close subewindows at all when main window closes. Qt surely propagates close events to widgets children in a background.

Yes, I agree with you. But I'm trying to close programmatically a MdiSubWindow along the run, not at the end.
I sent an image that should explicate the situation.

And one more thing that can be a reason - when you are overriding events always remember to call ancestor method

Oh, I didn't know that, thank you... but the problem persists.

BTW: sorry for late response.

Don't mind it: better a late answer that no one

[mchara]

Yes, I agree with you. But I'm trying to close programmatically a MdiSubWindow along the run, not at the end.

Still there should be only one close() called on child window of mdi area.

You may also make a breakpoint at frmmanager::close() and pass it step by step, to see which line causes crash.

Check also if you're not using any pointers to sub windows without checking if it is still valid(with deleteOnClose flag window is removed after closing).
You may tray calling setWindowFlags on subwindows (when created) to ensure it's not removed on close.
And see also QPointer<> class - it sets itself to NULL if pointed object was removed elsewhere.

[Raccoon29]

You may also make a breakpoint at frmmanager::close() and pass it step by step, to see which line causes crash.

Just after the closeEvent end (when exiting the function), when the control passes to Qt that has to hide the window, then there get reached the ASSERT that fails in qmdisubwindow.

You may tray calling setWindowFlags on subwindows (when created) to ensure it's not removed on close.

Sorry, I miss your aim: maybe you mean to make the window don't destroy on close removing WA_DeleteOnClose?

Anyway the program doesn't crash when I use the X button, but it does when I call my close() method, which just does a call to

viewport->getMDI(this)->close();

viewport->getMDI(this)->close();

To copy to clipboard, switch view to plain text mode 

but this is ehough to make it explode.

Could it be that calling this function I have the same Widget, where I call close from, that gets destroyed, and then when the controls come back to it, the run crashes because that widget doesn't exist anymore?

[mchara]

J

Sorry, I miss your aim: maybe you mean to make the window don't destroy on close removing WA_DeleteOnClose?

Yes, this is what i meant, sorry if it wasn't clear.


However, i thought about one more think - i had a bug other times i was removing some item in a slot and i missed that the slot was in instance that was removed. I mean maybe close called in you slot tries to delete instance while you're still executing slot in same instance.

So my suggestion is try not using close event at all.
i realized that close() is a slot , so you can simply connect buttons clicked() signal with sub window's close() slot. then you're sure that things happens in different eventloop iterations and code execution won't stay in implementation of removed object.

[wysota]

If you don't destroy a window when it is closed, the next window will not get activated. That's probably not what you want.

[mchara]

I didn't knew that, but it was suggested rather to check if crash is related to deleting or not.

[wysota]

You exchanged 15 posts without getting nowhere. I didn't want to cut in as obviously you chose another path to detect the problem, but since you are not making progress maybe it is time to try some other approach? I suggest taking a debugger, setting some breakpoints and stepping through the code. It will probably take two hours or so to detect the problem but then you'd be able to close in on the bug and fix it within a day.

[Raccoon29]

So my suggestion is try not using close event at all.

I tried bypassing the closeEvent, but nothing.

i realized that close() is a slot , so you can simply connect buttons clicked() signal with sub window's close() slot

Great idea this one, I've tried to connect the button to the QMdiSubWindow close, but it seems like if the slot is not activated, maybe this row is not correct:

QObject *mdi=(QObject*)viewport->getMDI(this);
connect(ui.tlbclose,SIGNAL(clicked()),mdi,SLOT(close()));

QObject *mdi=(QObject*)viewport->getMDI(this);
connect(ui.tlbclose,SIGNAL(clicked()),mdi,SLOT(close()));

To copy to clipboard, switch view to plain text mode 

I suggest taking a debugger, setting some breakpoints and stepping through the code. It will probably take two hours or so to detect the problem but then you'd be able to close in on the bug and fix it within a day.

All respect, but I'm using a debugger since third/fourth post of this thread.
If I have to put a signature somewhere to get it solved within a day, well, just tell me where

[...]but since you are not making progress[...]

I disagree.
As I am a developer and debugger as you are as well (I guess), you know that every little clue is important to approach the solution; so here I was collecting every possible clue from people that have much more Qt experience, knowing many more tricks and behaviors than me.

[wysota]

All respect, but I'm using a debugger since third/fourth post of this thread.

And what did you find out? Where did you place the breakpoints and which function of yours causes the program to enter an invalid state?

As I am a developer and debugger as you are as well (I guess), you know that every little clue is important to approach the solution; so here I was collecting every possible clue from people that have much more Qt experience, knowing many more tricks and behaviors than me.

We're just guessing here. If we can't reproduce a bug, how can we solve it? You are the one having access to the buggy code so just take that debugger and find out which list causes the assert.