SIMPLIFIED REPOST How to access "parent" from "closeEvent" ? SIMPLIFIED REPOST

Anonymous_Banned275

SIMPLIFIED REPOST

The SettingsDialog is a memeber of MainWindow_Bluetooth.
MainWindow_Bluetooth contains QMenu to control "windows" - an example "tileSubvindow" action.

SettingsDialog detect "close x" and "SettingsDialog closeEvent" is executed.

How do I code "closeEvebt" to execute MainWindow_Bluetooth "tileSubwindoiws"?

Please note
SettingsDialog instance gets passed MainWindow_Bluetooth "this" pointer as "parent".
I believe I need to gain access to this "parent" AND I DO NOT KNOW HOW.
Any skletal C++ code to access "parent" from "closeEvent'" would be appreciated.

PLEASE skip opinions , lecturing and other irrelevant to solution commentaries.
It is not helping.

This line of code is JUST an example , intend to pass "parent"

void SettingsDialog::closeEvent( QCloseEvent* event ( , QObject *parent) )
{

mpergand

@AnneRanch said in SIMPLIFIED REPOST How to access "parent" from "closeEvent" ? SIMPLIFIED REPOST:

QList<QObject*>  ppList = this->parent()->parent()->parent()->parent()->children();

QObject* p=this;

while(p->parent()) p = p->parent();
QObjectList  ppList = p->children();

sierdzio

If MainWindow is the parent of SettingsDialog, you can access it simply using parent() method. To get the access to proper methods in parent, you then need to cast it. Example:

void SettingsDialog::closeEvent( QCloseEvent* event)
{
  auto mainWindow = qobject_cast<MainWindow_Bluetooth*>(parent());

  if (mainWindow) {
    mainWindow->tileSubwindoiws();
  } else {
    qCritical() << "Whoops, something went wrong!" << parent();
  }

  // ... further event handling ...
}

Anonymous_Banned275

Thank you very much.
FINALLY something which makes sense, after all that .... i had to endure.
Unfortunately the value returned by the cast (?) is not valid.
BUT I firmly believe the concept is sound and this will give me a good start to fix this.
Thanks

PS
I may be passing wrong "parent" pointer to the SetingsDialog.
That is not that hard to verify...

Axel Spoerl

@AnneRanch

after all that .... i had to endure.

In one post you asked about iteration over parents. In another, you asked about a close event override being called or not. What you actually meant, was to call a specific method of a specific parent in a close event. A riddle resolved only here.

Now you victimise yourself and blame volunteers for correctly answering wrongly phrased questions. I’m baffled.

IMHO this attitude is not in line with the Qt forum’s code of conduct.

Anonymous_Banned275

@sierdzio i wonder if you coulkd help me tracking the hierarchy? I beliive the "parent " is NULL and that seems the be the issue.

I am going to post using "cut an paste " from word processor,so it is NOT properly formatted.

From"get go" the instance of MainWindow_Bluetooth(); has default "parent = NULL "....

Passin "paren t" to won't complie - which is not surprisng.
m_settings(new SettingsDialog(parent)),

Passing "this" compiles / runs but gives wrong "parent"
not surprising

m_settings(new SettingsDialog(this)),

Cut and paste

Table of Contents
Instance 1
MainWindow_Bluetooth *MWBT = new MainWindow_Bluetooth(); 1

Instance
MainWindow_Bluetooth *MWBT = new MainWindow_Bluetooth();
add_mdi_subwindow(MWBT);

Definition

  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(this)),
        m_settings(new SettingsDialog(parent)),  WON'T COMPILE
        //! [1]
        //! add rfcomm ??
        m_serial(new QSerialPort(this))
      //! [1]
    { // function\

I sincerely appreciate your help in resolving this, thanks .

Anonymous_Banned275

UPDATE
Here is a reason why I posted so many variations on the problem
At present , the cast returns null pointer, however . I can step thru the objects hierarchy tree and can see that the desired object and its VALID parent pointer is about four steps down the hierarchy tree...or up, depending on point of view ...and that is immaterial.
So, my next step is to iterate thru the "parent" hierarchy , until correct and valid object pointer is found or until desired "action" is found.

i am looking for Qt way to perform this iteration...
I am open to suggestions..

RTFM

Christian Ehrlicher

@AnneRanch said in SIMPLIFIED REPOST How to access "parent" from "closeEvent" ? SIMPLIFIED REPOST:

i am looking for Qt way to perform this iteration...

Already answered in your other post where you asked exactly the same question as now: https://forum.qt.io/topic/156460/how-to-iterate-parent-objects/4

Axel Spoerl

At present , the cast returns null pointer, however .

The cast doesn’t lie. If it returns nullptr, you are casting to the wrong type.
You could assign distinct object names to all your objects, then qDebug() would tell you that name.

RTFM

Yeah you should read more manuals. I agree. What does the F stand for?

JonB

@AnneRanch said in SIMPLIFIED REPOST How to access "parent" from "closeEvent" ? SIMPLIFIED REPOST:

I am open to suggestions..

As suggested in the past, what you want to achieve can be implemented correctly without any "parenting"/iterating/casting/closeEvent() and in a single line of code in your MainWindow_Bluetooth::MainWindow_Bluetooth():

connect(m_settings, &QDialog::finished, m_mdiarea, &QMdiArea::tileSubWindows);

Why don't you at least try this, instead of keep pursuing the parentage approach?

Anonymous_Banned275

As I said many times, there always is a different way to "skin a cat".

Your "connect" suggestions implies that "Dialogue is fished " ...
Finished doing what ?

That does not meet my spec - unless "clicking x" generates "finished"...
Can you elaborate on that?

Thanks

Christian Ehrlicher

Since clicking x = rejecting the dialog, the documentation tells you that finished is emitted: https://doc.qt.io/qt-6/qdialog.html#finished
You also have could try it out by yourself.

JonB

@AnneRanch said in SIMPLIFIED REPOST How to access "parent" from "closeEvent" ? SIMPLIFIED REPOST:

That does not meet my spec - unless "clicking x" generates "finished"...
Can you elaborate on that?

It does. Since it's a QDialog. Did you try it?

And even if it didn't we would simply make your override of closeEvent() emit a signal like finished or closed or whatever we like (3 lines of code) and the principle would still be to connect() that signal up in MainWindow_Bluetooth to a slot which does your tlleSubWindows() or whatever else you want to do (1 line of code). No parent stuff.

Anonymous_Banned275

OK, I 'll try it , but I have to bypass the current code first... maybe just deleting "closeEvent " will do .

JonB

@AnneRanch
Comment out existing closeEvent() override, or the code inside it, while you get this working.

Anonymous_Banned275

@JonB I have taken a different approach, - just added the suggested connect. That should also work since my current code does not do the "tileSunwindows". Unfortunately neither the connect code, hence more debugging is due.
I find the "finished" doc because DIALOG was "rejected" misleading.
As a user I am "working" with GUI commonly called "window". I am using its "feature " to close . As a user I could careless if the class is called "dialogue" - I am not using anything even suggesting I am "rejecting" the GUi.
As a coder I did the same - used visible GUI feature called "close"...
In an essence - "standard " (ISO term ?) "close" is being renamed "reject"...
Not cool... so well...
Cheers

JonB

QDialog emits finished when it is done() --- no matter accepted, rejected, or press "close" button. It just means finished with the dialog, and only applies to a dialog. There are no "standard ISO terms" for anything. If you don't want to use finished because you don't like the word that's up to you. If you want to define your own signal with a different word:

// In settingsdialog.h
signals:
    void closed();

// In settingsdialog.cpp
void SettingsDialog::closeEvent( QCloseEvent* event)
{
    emit closed();
}

// In MainWindow_Bluetooth::MainWindow_Bluetooth()
// any of the following
connect(m_settings, &SettingsDialog::closed, m_mdiarea, &QMdiArea::tileSubWindows);
connect(m_settings, &SettingsDialog::closed, this, &MainWindow_Bluetooth::anySlotYouCareToWrite);
connect(m_settings, &SettingsDialog::closed, this, [] () { qDebug() << "What to do when SettingsDialog closed"; });

Whichever this connection of signal to slot is the correct way to do it rather than attempting to walk up SettingDialog's parent hierarchy.

Anonymous_Banned275

@JonB OK, then I will have to ask this - what is "being done" in my case?
The dialog is added as QMdiArea subwindow and has few tasks to do.
There is no task indicating that the dialogue is "done" and that is irrelevant to task "close" and process such "close" .
Dialog tasks and "close" are independent.
I am not disputing your connect approach , but it extreme - using "done" is like say "today is Monday" so lets close the window.

Besides - I think down the line
if the "dialog" is "rejected" how am I doing to apply - "restore previous display of subwindows "?

I realize this is mater of semantics - but does "close" means just that and the object is still in memory ?

And no , I am not that far in code .....

JonB

@AnneRanch
QDialog::finished() is a signal which, so far as I understand, is emitted by a QDialog whenever it gets closed --- be that by pressing a button or closing it with the "X" button. That is what you were trying to capture when you were overriding closeEvent(). I believe this finished signal gets emitted in the same circumstance, which is what you were looking for.

Why don't you start with no more or less than:

connect(m_settings, &SettingsDialog::finished, this, [] () { qDebug() << "What to do when SettingsDialog closed"; });

You can add this line (in MainWindow_Bluetooth::MainWindow_Bluetooth()) regardless of what else you have there/without changing anything of your own. Then see when that message appears, e.g. we're hoping it does when you close the settings dialog, since that is what you were looking for. Assuming it does, you can then connect it to whatever you actually want to from the main window do when the dialog gets closed.

Anonymous_Banned275

@JonB OK, getting somewhere,,, since I got the "cut ans paste " save and ready let me post this and the reply to your last post.

This is is all working as "single stage iteration" and what is left is to extend the code "up stream" - up the current hierarchy until CORRECT class is activated.
I do not have a clue how to implement that!!!

I have bee looking at various QTree and so far no success .

The issues are - there are many intermediate classes / objects hence the up- stream object cannot be explicitly named - it has to be machine friendly and probably "all the way " to QObject base class.

Now to the use of "finished".
I am not saying it is not usable, however , it seem to just duplicate the "closeEvent".
Secondly
the "close" task HAS to be implemented to ALL subwindows AND according to the doc "closeEvent" can be "reimplemented" up the hierarchy tree. In that case the "parent" class would contain the common code - no need to have each subwindow to process the "closeEvent". If "finished " is used - I would have to have connect all over the place...

BUT I am not convinced this "reimplementing " of "closeEvent" actually works - the doc SPECIFICALLY say "it MAY work..."
With that - I may have to use your "connect" approach anyway....

I do appreciate your assistance .

void SettingsDialog::closeEvent( QCloseEvent* event )
{
#ifdef RETILE
    text = "\t#ifdef RETILE \n";
    text += "\t\t\tTRACE START Retile mdiArea subwindows ....  ";
    text += " ";
    //text += " TASK  initActionsConnections() ";
    text += Q_FUNC_INFO;
    text += QString::number(__LINE__);
    qDebug().noquote() << text;

//    text =" parent ???";
//    text += parent()->objectName();
//     qDebug().noquote() << text;
#endif


#ifdef BYPASS
    //event->accept();   // what does it do ??
    emit PassMessage(text,0);
    // setup message passing QString for now
    connect(SDD,SIGNAL(PassMessage(QString,int)),this,SLOT(PostMessage(QString,int)));
#endif

    // Accept the event to allow the window to close
    event->accept();  // TOK
    // looking for action = tileSubwindows
    QString textMmatch = "tileSubwindow";
    // access to QMdiArea
    // who is immedate upstrem in hirerarchy?
    QObject *object = qobject_cast<QObject*>(parent()); // this->parentWidget());
    QMdiSubWindow* mdiArea = qobject_cast<QMdiSubWindow*>(this->parentWidget());
    // doesit have action = textMatch ?
    QList<QObject*> list = object->children();
    foreach(auto *action,list)
    {
        if( action->objectName().contains(textMmatch))
        {
            text = " /t/t/t found match ";
        }
        else
        {
            text = " Match not found continue search... ";
        }
        text += action->objectName();
        qDebug().noquote() << text;
    }
    text += Q_FUNC_INFO;
    text += QString::number(__LINE__);
    qDebug().noquote() << text;


    return;

Anonymous_Banned275

@AnneRanch Here is my current "solution" , and it is a embarrassing hack.

Can anybody smarter than me put this into nice loop ?
ANY loop...

    QString textMmatch = "actionTile_subwindows";

    // test code here

HACK 
    **QList<QObject*>  ppList = this->parent()->parent()->parent()->parent()->children();**


    foreach(auto *action,ppList)
    {
        if( action->objectName().contains(textMmatch))
        {
            text = " \t\t\t found match ";
            text += action->objectName();
            qDebug().noquote() << text;
            break; //continue;
        }
        else
        {
            text = " Match not found continue search... ";
        }
        text += action->objectName();
        qDebug().noquote() << text;
    }
    text += Q_FUNC_INFO;
    text += QString::number(__LINE__);
    qDebug().noquote() << text;