What happens after closing and before destruction?

[Raccoon29]

Hi all,

I have two related questions to ask:
1) Is it admitted to set the flag Qt::WA_DeleteOnClose for a QWidget, beyond that for the MDI subwindow that contains it?

If the answer to the 1 is "Yes", the second question:
2) What does a QWidget do right after accepting the closeEvent and before its desctruction?
Because right now this function:

void frmarticle::closeEvent(QCloseEvent *event)
{
    if(!maybeSave())  // check for modifies apported
    {
    	event->ignore(); //modifies apported stop the closement
    	return;
    }
 
    viewport->close(Article); //nullifies pointers
    event->accept(); //accepts close event, it is supposed to destroy this widget now, is it?
}
// now quits the closeEvent and the program raise exception, before calling the destructor

void frmarticle::closeEvent(QCloseEvent *event)
{
    if(!maybeSave())  // check for modifies apported
    {
    	event->ignore(); //modifies apported stop the closement
    	return;
    }

    viewport->close(Article); //nullifies pointers
    event->accept(); //accepts close event, it is supposed to destroy this widget now, is it?
}
// now quits the closeEvent and the program raise exception, before calling the destructor

To copy to clipboard, switch view to plain text mode 

So, if I would know what it does after close event and before destructor, I could debug it; if you have any other suggestion don't be shy, I accept everything.

[Raccoon29]

No one know where control goes after closing a Widget in a MDI system??

[wysota]

You can use WA_DeleteOnClose for any widget you want. After an event is accepted, the control is returned to the event loop and the widget is most probably scheduled for deletion using deleteLater() (I'm not sure of that, but that's a quite safe thing to assume) and is deleted when the event queue reaches the delayed destruction event.

I'd suggest using a debugger to see what and why crashes. Most probably you either have a null or invalid pointer or you are trying to delete an object inside a slot connected to a signal originating from the object itself.

[Raccoon29]

Thank you, you have just made me find the courage to install the debug environment

Once I have debugged it, I'll post here more informations.
Thank you for the suggestion.

[Raccoon29]

Ok, debug installed and working, from its scan resulted the following (now we'll see how much deep is your Qt knowledge ):

The application after closeEvent and before destruction stopped the run with the message:
ASSERT failure in QList<T>::at: "index out of range", file ../../include/QtCore/../../src/corelib/tools/qlist.h, line 391

What is the verdict?

[wysota]

"after closeEvent" meaning "after closeEvent returns" or "after closeEvent is called"? It'd say your viewport->close(Article) tries to reference some item in some list and fails because the list is smaller than it expects.

[Raccoon29]

"after closeEvent" meaning "after closeEvent returns" or "after closeEvent is called"?

meaning "after closeEvent accepts the event and return", and I remember that the widget closed is a MdiSubWindow with WA_DeleteOnClose that contains frmarticle (inherited from QWidget)

It'd say your viewport->close(Article) tries to reference some item in some list and fails because the list is smaller than it expects.

Yes, I thought it too, but viewport->close(Article); is called to do just this:

void CViewports::close(EViewport win)
{
    switch(win)
    {
        // Article
        case 1:
        {
            if(pArticle) //pointer to frmarticle, not null for sure
            {
                pArticle=NULL;
                wArticle=NULL;
            }
 
            break;
        }
    [...]
}

void CViewports::close(EViewport win)
{
    switch(win)
    {
        // Article
        case 1:
        {
            if(pArticle) //pointer to frmarticle, not null for sure
            {
                pArticle=NULL;
                wArticle=NULL;
            }

            break;
        }
    [...]
}

To copy to clipboard, switch view to plain text mode 

Maybe, since the problem seems to be some list, could be the QTableWidget present in frmarticle be involved in the problem, or I'm totally off-road?

[aamer4yu]

The application after closeEvent and before destruction stopped the run with the message:
ASSERT failure in QList<T>::at: "index out of range", file ../../include/QtCore/../../src/corelib/tools/qlist.h, line 391

Try to trace the lists you are using in the application.

[Raccoon29]

Try to trace the lists you are using in the application.

I would do it, but I'm not using QLists at the moment, and noteven objects that inherit from it.

[wysota]

Of course you are. The mdi window keeps a list of its child windows. You are interacting with it when closing a child window. Maybe you simply shouldn't use the attribute. I suggest you take a look at the source code of the mdi framework and see what happens if you close a child window.

[Raccoon29]

Of course you are. The mdi window keeps a list of its child windows. You are interacting with it when closing a child window. Maybe you simply shouldn't use the attribute. I suggest you take a look at the source code of the mdi framework and see what happens if you close a child window.

Yes,yes, you are right, I noticed it but only after the last post, and then I forgot to edit.
Anyway I've given a look a the source like you suggest, but still the problem is in the shadow.
I found the assert that fails, but still I don't understand why; I'm going to break my head for the second time trying to understand how that subwindows list index works

EDIT: I've already tried to cutout the attribute, but the problem persists.

[wysota]

Let's try from the beginning... Could you describe the goal you are trying to obtain? Maybe instead of trying to fix your solution we'll find some other solution that works.

[Raccoon29]

Could you describe the goal you are trying to obtain?

My goal is to close the windows without the program be destroyed

The trouble is that the description requires many "if", anyway here follows a "once for all" description.

=ENVIRONMENT=
It is a QMdiArea workspace.
There are three QMdiSubWindows: ViewArticles that makes open Article that makes open Manager. I say "makes open" because between them there are no dependencies, no one of them is parent of the other: they all refer to the master class CViewports which manage them all just opening and closing them.
Every QMdiSubWindow has the WA_DeleteOnClose attribute.

=PROBLEM=
Now, when Article calls Manager (to do a quick search), the same Article becomes a wandering bomb, because if it get closed, the whole program explodes with the famous error:

ASSERT failure in QList<T>::at: "index out of range", file ../../include/QtCore/../../src/corelib/tools/qlist.h, line 391

=DEBUG CLUES=
-Opened Article, opened Manager, closed Manager (now Article is expected to boom on close, but...), made lost focus to the Article window (so give focus to ViewArticles, or just switch to another program and then come back) and Article get defused and even closed the program continues normally.

-Other windows (out of Article) call Manager, and all of them become wanding bombs just like Article.

-If Manager get not called all works as expected.

-When closing Article before assertion failed, the number of opened windows in QMdiArea::subWindowList seems to be right (=2).


These are the main clues I found, I would post some code too, but there are over twenty files, so I'll post them on request if needed.
But anyway what is important and that I really can't understand is why the loss of the focus heals the error!

Every question is welcome, just I'd like to know why all this!

[wysota]

One step at a time...

Let's try with a minimal application that consists of an mdiarea that has a child window that can open other windows in the mdi space using a button or something like that. No special attributes or anything. When you have that done and verify it does not crash, you can continue with putting some logic of yours there.

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