Implementing / reimplementing "close event"????
-
@Axel-Spoerl no problem
@AnneRanch I'm trying to guess ... You have a mainWindow with QMdiArea (let's call it mdiArea) and you have a opened dialog window (SettingsDialog). Now you want to call mdiArea->tileSubWindows() after closing the SettingsDialog.Then, If you cubclassed SettingsDialog from the QDialog then there is finished() signal you can connect from the MainWindow (rough example)
// in MainWindow.cpp MainWindow::MainWindow() { auto mdiArea = new QMdiArea(this); //... auto settingsDialog = new SettingsDialog(this); connect(settingsDialog, &SetingsDialog::finished, mdiArea, &QMdiArea::tileSubWindows); }
@medyakovvit Thanks, I have been collecting examples of solutions and they seems to point to use connect.
I am writing a test code to process SIGNAL/SLOT , simple passing messages, to be later adapted to do the task of re-tilling the mdiArea.
I like the idea to monitor "finished" , not sure where / what process it can monitor. The actual closure of the sub=window is already detected by "closeevent" being run. -
This post is deleted!
-
This post is deleted!
Thank you very much.
Looks as a variation code of what I did .
Two differences - I did try to find parent as QWidget - hence
I did not used cast or template QMdiArea,Unfortunately
I do not see any "parent " window title changes -
and I happen to have 6 subwindows opened .I think it builds a new "parent " - as my code did.
I am going to repost the "parent" object just to continue to try to fix this.
MainWindow_Bluetooth::MainWindow_Bluetooth(QWidget *parent) : QMainWindow(parent), m_ui(new Ui::MainWindow_Bluetooth), m_status(new QLabel), m_console(new Console), // insert MDI area here ??9 **m_mdiarea(new QMdiArea),** m_settings(new SettingsDialog), //! [1] //! add rfcomm ?? m_serial(new QSerialPort(this)) //! [1] { // function\
I think part of the issue is because
m_mdiarea(new QMdiArea),
is member of
MainWindow_Bluetooth::hence MainWindow_Bluetooth is "grandpa " - sort off.
but that shoud not make a difference.
@Publicname878 said in Implementing / reimplementing "close event"????:
QMdiSubWindow* mdiParent = qobject_cast<QMdiSubWindow*>(this->parentWidget()); if (mdiParent) { // You have the parent QMdiSubWindow, do something with it mdiParent->setWindowTitle("Parent Window Title"); // Other operations with mdiParent } else { // Handle the case where parentWidget() is not a QMdiSubWindow } // Accept the event to allow the window to close event->accept();
Again , appreciate your help, very much.
-
Thank you very much.
Looks as a variation code of what I did .
Two differences - I did try to find parent as QWidget - hence
I did not used cast or template QMdiArea,Unfortunately
I do not see any "parent " window title changes -
and I happen to have 6 subwindows opened .I think it builds a new "parent " - as my code did.
I am going to repost the "parent" object just to continue to try to fix this.
MainWindow_Bluetooth::MainWindow_Bluetooth(QWidget *parent) : QMainWindow(parent), m_ui(new Ui::MainWindow_Bluetooth), m_status(new QLabel), m_console(new Console), // insert MDI area here ??9 **m_mdiarea(new QMdiArea),** m_settings(new SettingsDialog), //! [1] //! add rfcomm ?? m_serial(new QSerialPort(this)) //! [1] { // function\
I think part of the issue is because
m_mdiarea(new QMdiArea),
is member of
MainWindow_Bluetooth::hence MainWindow_Bluetooth is "grandpa " - sort off.
but that shoud not make a difference.
@Publicname878 said in Implementing / reimplementing "close event"????:
QMdiSubWindow* mdiParent = qobject_cast<QMdiSubWindow*>(this->parentWidget()); if (mdiParent) { // You have the parent QMdiSubWindow, do something with it mdiParent->setWindowTitle("Parent Window Title"); // Other operations with mdiParent } else { // Handle the case where parentWidget() is not a QMdiSubWindow } // Accept the event to allow the window to close event->accept();
Again , appreciate your help, very much.
@AnneRanch
Kindly allow me to extend my last post.
My objective is to solve the issue, not to argue terminology.
However , I feel it would be helpful to back-up and take a different look at this.
It has been established that “SettingsDialog”
CLASS inherits from QDialog.
Then “SettingsDialog “ is a added to QMDIArea.
In plain C++ terminology – “SettingsDiloog” class is
coded as a member of QMDIArea class.
Hence it should have access to QMDIArea class and its members / methods – if properly coded,
And that “access code “ , "tilewindws" ( method of QMDIArea) as an example, is the missing piece in “closeevent” function. . -
@AnneRanch
Kindly allow me to extend my last post.
My objective is to solve the issue, not to argue terminology.
However , I feel it would be helpful to back-up and take a different look at this.
It has been established that “SettingsDialog”
CLASS inherits from QDialog.
Then “SettingsDialog “ is a added to QMDIArea.
In plain C++ terminology – “SettingsDiloog” class is
coded as a member of QMDIArea class.
Hence it should have access to QMDIArea class and its members / methods – if properly coded,
And that “access code “ , "tilewindws" ( method of QMDIArea) as an example, is the missing piece in “closeevent” function. .Hence it should have access to QMDIArea class and its members / methods – if properly coded,
And that “access code “ , "tilewindws" ( method of QMDIArea) as an example, is the missing piece in “closeevent” function. .If the
SettingsDialog
class knows a pointer to theQMDIArea
, it will be able to access its public members. Not private or protected ones.
I don't know what you mean by "access code" and "titlewindws".QMDIArea
doesn't have such members or similar ones. -
@AnneRanch
Kindly allow me to extend my last post.
My objective is to solve the issue, not to argue terminology.
However , I feel it would be helpful to back-up and take a different look at this.
It has been established that “SettingsDialog”
CLASS inherits from QDialog.
Then “SettingsDialog “ is a added to QMDIArea.
In plain C++ terminology – “SettingsDiloog” class is
coded as a member of QMDIArea class.
Hence it should have access to QMDIArea class and its members / methods – if properly coded,
And that “access code “ , "tilewindws" ( method of QMDIArea) as an example, is the missing piece in “closeevent” function. .@AnneRanch said in Implementing / reimplementing "close event"????:
In plain C++ terminology – “SettingsDiloog” class is
coded as a member of QMDIArea class.
Hence it should have access to QMDIArea class and its members / methods – if properly coded,If your
QMdiArea
has aSettingsDialog *m_settingsDialog
member variable or similar theSettingsDialog
ought not have any access to its parentQMdiArea
or any members the latter has. That is "proper coding" for object-oriented/C++ programming. It simply should never need to or try to access itsparent
. Parents know about children, but children should not know about parents.Any work which requires knowledge of the
QMdiArea
should be done in theQMdiArea
class, not in theSettingsDialog
code, theQMdiArea
knows about itself and the (public) methods of theSettingsDialog
it holds. Anything you want to do from theSettingsDialog
to affect theQMdiArea
should be done by passing results back or emitting signals which theQMdiArea
has connected to its own slots, rather than the dialog reading/writing/calling anything in the MDI area viaparent
. -
Hence it should have access to QMDIArea class and its members / methods – if properly coded,
And that “access code “ , "tilewindws" ( method of QMDIArea) as an example, is the missing piece in “closeevent” function. .If the
SettingsDialog
class knows a pointer to theQMDIArea
, it will be able to access its public members. Not private or protected ones.
I don't know what you mean by "access code" and "titlewindws".QMDIArea
doesn't have such members or similar ones.Thanks for your reply.
QMDIArea GUI "menu bar "has "window control " submenu
and that is where "action" and its access
actionTile_subwindow
reside.
This action is part of the menu and works fine when the menu is directly clicked in mdiArea main window.
"closeevent" function should be able to access it too.
As you pointed out, I will make sure the entire path from "closeevemt" is coded as public, at minimum. .
At this point it looks as the QMDIArea is not accessible at all from "closevent" function.
Maybe some intermediate test function / test steps are due too.
-
Thanks for your reply.
QMDIArea GUI "menu bar "has "window control " submenu
and that is where "action" and its access
actionTile_subwindow
reside.
This action is part of the menu and works fine when the menu is directly clicked in mdiArea main window.
"closeevent" function should be able to access it too.
As you pointed out, I will make sure the entire path from "closeevemt" is coded as public, at minimum. .
At this point it looks as the QMDIArea is not accessible at all from "closevent" function.
Maybe some intermediate test function / test steps are due too.
@AnneRanch
MORE "stuff"
I am stepping thru this code and looking at debug messages.
QObject *pTEST = this->parent(); text = "pTEST->objectName()" ; text += pTEST->objectName(); qDebug().noquote() << text; QWidget *pTEST_WIDGET = this->parentWidget(); text = "pTEST_WIDGET ->objectName()" ; text +=pTEST_WIDGET->objectName(); qDebug().noquote() << text;
there are plenty of them, and they are output in some kind of process order / levels - unfortunately none of them say explicitly "object name " , and the above code gives no text output to identify the "parent" .
My next step is to get some kind of meaningful output from the first level - perhaps "parent" and its "children" pointers / names and proceed from there to next level.
-
@AnneRanch
MORE "stuff"
I am stepping thru this code and looking at debug messages.
QObject *pTEST = this->parent(); text = "pTEST->objectName()" ; text += pTEST->objectName(); qDebug().noquote() << text; QWidget *pTEST_WIDGET = this->parentWidget(); text = "pTEST_WIDGET ->objectName()" ; text +=pTEST_WIDGET->objectName(); qDebug().noquote() << text;
there are plenty of them, and they are output in some kind of process order / levels - unfortunately none of them say explicitly "object name " , and the above code gives no text output to identify the "parent" .
My next step is to get some kind of meaningful output from the first level - perhaps "parent" and its "children" pointers / names and proceed from there to next level.
@AnneRanch Sorry, but I still don't get what is your goal.
About the object name... If you create a widget using Qt Designer then it has an automatically generated name. If you create a widget in your code then the objectName() is empty by default. You need to set its name yourself by calling setObjectName("SomeWidgetName"). -
@AnneRanch Sorry, but I still don't get what is your goal.
About the object name... If you create a widget using Qt Designer then it has an automatically generated name. If you create a widget in your code then the objectName() is empty by default. You need to set its name yourself by calling setObjectName("SomeWidgetName").EDIT
Kindly check my next post.
I just do not see why I cannot get any name or description.
I just want to read anything , in human form, no numbers oi pointers etc. , to identify the object.Thanks
Here is my test / verify code and still no text / name returned.
SettingsDialog *SD = new SettingsDialog(this); // text = " SettingsDialog(this) name "; SD->setAccessibleName(text); text = " SD->accessibleName()"; text += SD->accessibleName(); qDebug().noquote() << text; NewMdiSub(SD); text = " SettingsDialog(this) name "; SD->setAccessibleName(text); text = " SD->accessibleName()"; text += SD->accessibleName(); qDebug().noquote() << text;
I'll try to step thru it....
-
EDIT
Kindly check my next post.
I just do not see why I cannot get any name or description.
I just want to read anything , in human form, no numbers oi pointers etc. , to identify the object.Thanks
Here is my test / verify code and still no text / name returned.
SettingsDialog *SD = new SettingsDialog(this); // text = " SettingsDialog(this) name "; SD->setAccessibleName(text); text = " SD->accessibleName()"; text += SD->accessibleName(); qDebug().noquote() << text; NewMdiSub(SD); text = " SettingsDialog(this) name "; SD->setAccessibleName(text); text = " SD->accessibleName()"; text += SD->accessibleName(); qDebug().noquote() << text;
I'll try to step thru it....
@AnneRanch
partially SOLVED
Using option 1 , which passes the " parent" .
Parent children contain the required "action" - re -tile the QMdiArea subwindows.option 1 SettingsDialog *SD = new SettingsDialog**(this)**; option 2 SettingsDialog *SD = new SettingsDialog();