Implementing / reimplementing "close event"????

Anonymous_Banned275

@Axel-Spoerl Maybe the misunderstanding begins here: closeEvent() is by no means an object. It's a function. It can't be a parent or a child.

It is no misunderstanding , I have been looking at it as function ,but initially I was told it is an object.

Terminology does not help me.
Since my initial question got lost somewhere,
here is a short version :

AFTER "close" by clicking "x"

HOW do I get to execute
"tileWindows" from within

"closeevent" FUNCTION?

PS
The function is implemented / executed in
mdiarea subwindow object. .

medyakovvit

@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);
}

Anonymous_Banned275

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

Publicname878

This post is deleted!

Anonymous_Banned275

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.

Anonymous_Banned275

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

Axel Spoerl

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 SettingsDialogclass knows a pointer to the QMDIArea, 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". QMDIAreadoesn't have such members or similar ones.

JonB

@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 a SettingsDialog *m_settingsDialog member variable or similar the SettingsDialog ought not have any access to its parent QMdiArea 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 its parent. Parents know about children, but children should not know about parents.

Any work which requires knowledge of the QMdiArea should be done in the QMdiArea class, not in the SettingsDialog code, the QMdiArea knows about itself and the (public) methods of the SettingsDialog it holds. Anything you want to do from the SettingsDialog to affect the QMdiArea should be done by passing results back or emitting signals which the QMdiArea has connected to its own slots, rather than the dialog reading/writing/calling anything in the MDI area via parent.

Anonymous_Banned275

@Axel-Spoerl

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.

Anonymous_Banned275

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

medyakovvit

@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").

Anonymous_Banned275

@medyakovvit

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

Anonymous_Banned275

@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();