What happens after closing and before destruction?

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