How to pass data to the thread of a modal dialog
-
Here is what I did :
MyObject * pObj = theSingleton.create(); MyDialog dialog( pObj, this ); dialog.exec();Since the instance of MyObject is created in the current thread, I get crash while accessing its data in the dialog thread. This is "normal" in the frame of Qt.
MyObject is plenty of attributes of type QList, QString and QMap.How could I elegantly pass the MyObject data, created in the main thread, to the modal dialog ?
Many thanks in adavance for your support.
Best regards.
-
@gav007 said in How to pass data to the thread of a modal dialog:
How could I elegantly pass the MyObject data, created in the main thread, to the modal dialog ?
You can't have a dialog outside the main thread.
Passing data around through thread boundaries works either with locking mechanisms or signals and slots -
@gav007 said in How to pass data to the thread of a modal dialog:
How could I elegantly pass the MyObject data, created in the main thread, to the modal dialog ?
You can't have a dialog outside the main thread.
Passing data around through thread boundaries works either with locking mechanisms or signals and slots@Christian-Ehrlicher
Many thanks.
I prevent from the concurrent access to the data by design. Hence I avoid the use of locking mechanism.About signals and slots, the object to be passed is so full of data, I do not find elegant to pass all the data with signals.
Is the problem of thread ownership solved with such a code :
MyObject * pObj = theSingleton.create(); MyDialog dialog( this ); connect( this, &MainWindow::theObjectToHandle, &dialog, &MyDialog::HandleObject ); connect( &dialog, &MyDialog::objectModified, this, &MainWindow::getObjectModified ); emit theObjectToHandle( pObj ); dialog.exec();and in the dialog :
void MyDialog::HandleObject( MyObject * pObj ) { ... modify the object emit objectModified( pObj ); accept(); }I will test this code, but I'm interrested by your answer anyway.
Best regards.
-
@Christian-Ehrlicher
Many thanks.
I prevent from the concurrent access to the data by design. Hence I avoid the use of locking mechanism.About signals and slots, the object to be passed is so full of data, I do not find elegant to pass all the data with signals.
Is the problem of thread ownership solved with such a code :
MyObject * pObj = theSingleton.create(); MyDialog dialog( this ); connect( this, &MainWindow::theObjectToHandle, &dialog, &MyDialog::HandleObject ); connect( &dialog, &MyDialog::objectModified, this, &MainWindow::getObjectModified ); emit theObjectToHandle( pObj ); dialog.exec();and in the dialog :
void MyDialog::HandleObject( MyObject * pObj ) { ... modify the object emit objectModified( pObj ); accept(); }I will test this code, but I'm interrested by your answer anyway.
Best regards.
-
@gav007 Why don't you simply pass the data by reference to the constructor of your dialog? There is no need to use signals/slot for this in this case.
@jsulm Thanks for this suggestion.
Do you mean that, if I change my original code as follow (changing the pointer to reference), the thread ownership of my object shall be solved ?
MyObject * pObj = theSingleton.create(); MyDialog dialog( *pObj, this ); dialog.exec();Where the dialog constructor looks like this:
MyDialog::MyDialog( MyObject & obj, QWidget *parent = nullptr )Regards
-
@jsulm Thanks for this suggestion.
Do you mean that, if I change my original code as follow (changing the pointer to reference), the thread ownership of my object shall be solved ?
MyObject * pObj = theSingleton.create(); MyDialog dialog( *pObj, this ); dialog.exec();Where the dialog constructor looks like this:
MyDialog::MyDialog( MyObject & obj, QWidget *parent = nullptr )Regards
-
@jsulm said in How to pass data to the thread of a modal dialog:
as pointer.
That was I did in the original code and in such a case, I can tell that all the data of my object are not available to the dialog thread. This sounds normal to me since my object is owned by the main thread and not by the dialog thread.
Do I miss something ?
Regards
-
@jsulm said in How to pass data to the thread of a modal dialog:
as pointer.
That was I did in the original code and in such a case, I can tell that all the data of my object are not available to the dialog thread. This sounds normal to me since my object is owned by the main thread and not by the dialog thread.
Do I miss something ?
Regards
@gav007 As @Christian-Ehrlicher already said: you can't run dialog outside of the UI thread. And in your code I can't see where you start other threads. So, why do you think your dialog is running in another thread? Dialogs do NOT run in their own threads, they run in the main/UI thread.
-
@gav007 As @Christian-Ehrlicher already said: you can't run dialog outside of the UI thread. And in your code I can't see where you start other threads. So, why do you think your dialog is running in another thread? Dialogs do NOT run in their own threads, they run in the main/UI thread.
@jsulm OK, my mistake
I thought that the exec() call creates its own thread with its own event loop.Then why all the QString, QList and QMap of my object are not available when processing the object in my dialog ?
PS: "Not accessible" is what my debugger said at the crash time
-
@jsulm OK, my mistake
I thought that the exec() call creates its own thread with its own event loop.Then why all the QString, QList and QMap of my object are not available when processing the object in my dialog ?
PS: "Not accessible" is what my debugger said at the crash time
@gav007 said in How to pass data to the thread of a modal dialog:
PS: "Not accessible" is what my debugger said at the crash time
Where exactly did your app crash? Somewhere inside your dialog? Sometimes the debugger fails to show content of variables in QtCreator, but this does not mean that they are not available in general.
-
I found my mistakes: a hide and seek game between destructor and copy constructor made my object data unavailable. "Not accessible" data were due to a former destruction (this highlight a very bad design ! ). 1st mistake.
Usually, when I met the "not accessible" issue from the debugger, it was due to invalid concurrent access. I made the 2d mistake to directly invoke this reason.
Well ! Many thanks to @jsulm and @Christian-Ehrlicher for their support.
Very instructive topic for me :-)
Best regards
