Closing a QDialog from another class

franku

Hi, sorry. I mean:

@
void Frontcontroller :: openInsertArticleWin()
{
qDebug() << "Exec-Thread" << QThread::currentThreadId();

    seconW = new W2();  //This is a QDialog
    seconW->setAttribute( Qt::WA_DeleteOnClose, true );
    seconW->exec&#40;&#41;; 
}

@

and

@
void Frontcontroller :: closeInsertArticleWin()
{
qDebug() << "Close-Thread" << QThread::currentThreadId();

    seconW->close();
}

@

Exec-Thread and Close-Thread must not be different. If they are, you have to use some event-queue to do it. If you figure out the IDs, we can try to find a solution.

QMatt

Thank you again franku.
Here is the debug output:

@
Exec-Thread: 0xc60
Close-Thread 0xc60
@

So the open and close threads seems to be the same

mlong

franku: I'm not sure how threads enter the picture. I'm not sure that this is a multithreaded situation at all... the exec() call was a QDialog::exec(), not a QThread::exec(), as I understand it.

mlong

Is the dialog modal? (I assume so, since you're using exec() to open it, instead of show().) If so, have you tried calling accept() or reject() instead of close() to close it? I'm not sure off the top of my head how calling close() on a running modal dialog works, as there may be pending events in its event loop, etc. Also, if there's a DeleteOnClose situation, are you sure that the variable isn't still being referenced somewhere else?

Can you get a working backtrace from the debugger when it crashes?

QMatt

Hi mlong, no, the Dialog is not modal, but i have tried to it to modal and call show() instead of exec(), I have tried to call show() without setModal(), nothing change.
Yes, I have tried to call accept() and reject instead of close() (my first attempt, actually), nothing and nothing.
What seems suspicious is that when closing the Dialog, debugging of the poniter returns a QObject (0x0)

webmaster.skelton

If it is returning a QObject(0x0) you are get a Null pointer exception. Somewhere along the way it is losing reference to your pointer, though from the code you have given I would not be sure where at.

franku

bq. I’m not sure how threads enter the picture.

Well, some thread must execute the exec() method of the Dialog. In most cases I think this is done by the thread that runs the gui. But I did not know if QMatt uses another thread than the guithread to close() the window. So I wanted to be sure before we think about other possibilities.

bq. ...if there’s a DeleteOnClose situation, ...

In that case you could use dialog->setAttribute(Qt::WA_DeleteOnClose, false) to improve that the object isnt't deleted after finishing the event loop. Afterwards you have to delete it manually (for a quick test just don't delete it).

But as mlogn and webmaster. mentioned above, what does the debugger say?

QMatt, did you run the code step by step to see what is going on? You may want to create some breakpoints in each method and see what happens, especially when the object is deleted.

QMatt

Hi guys and thanks a lot for your patience with me...
Trying to start debugging (Debug -> Start Debugging), I receive this message:
@
The inferior stopped because it received a signal from the Operating System.
Signal name: SIGSEGV
Signal meaning: Segmentation fault
@

And a disassembler appears with an ASM code with a right arrow @ line n. 8
How (and if) I can print a Stack Trace or someting similar?

QMatt

Ok so... probably the night brings counsel, or maybe I am stupid...
When I call exec() on secondW, I need to use the Frontcontroller in this window, so I do
@
Frontconrtoller fc;
...
...
...
void insertArticleWin :: on_cancelButton_clicked() { fc.closeWIN2(); }
@

but this is a new instance of Frontcontroller, a different object, right? So the pointer to secondW is set to NULL... and so I just made this change

@
Frontconrtoller fc;
...
...
...
void insertArticleWin :: on_cancelButton_clicked() { fc.secondW = this; fc.closeInsertArticleWin(); }
@

And now all seems to work... do you think what I am doing is theoretically wrong?

blobfish

You are creating modal dialog and trying to use it like a modeless one. exec blocks until the dialog is closed and then returns. So in a true modal environment, your closeInsertArticleWin() function couldn't be called until after the dialog is closed. It sounds like to me that you should be working with a modeless dialog (QDialog::show) instead of QDialog::exec and set your qobject parenting. I don't think you want deleteOnClose. Modeless dialog should be constructed upon app start shown and hidden by controller and deleted on app shutdown.

you should check seconW before using it. That is what qpointer is for. i.e. @if (seconW)
seconW->close();@

If you can, post something we can easily build.