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

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;

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

Pl45m4

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

QObject* p=this;

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

@mpergand A piece of art lmao :D

Anonymous_Banned275

Thanks a million .. true piece of art code = KISS !
I am not just saying this , but this morning I came up with identical idea... but I was not sure how to implement the while loop.
Woks great, skips over all of the intermediate classes...
And most of all - no RTFM,
I do appreciate your help.

Anonymous_Banned275

@mpergand Hello,
I have posted more stuff related to my task and it may look as negative toward you.
I am posting this to make sure it is not interpreted that way and woudl like to let you know that I do appreciate all the help you have given me.
The whole idea of automatic re-tillling of QMdiArea subwindows after one is deleted , was really just "bells and whistles ",
nice to have and not essential for my project.
This is / was an extremely (sic?) positive , hence beneficial experience for me, with an exception of uncalled for "contributions" AI / RTFM style.
I realized that big part of the mess was my silly way to keep the Qt example and add QMdiArea to it. Then I ended up with two instances of same class and it was not easy to keep track of which is which.

It really does not matter I did not end up with working code, but I sure can reuse it in my next "GUI class hierarchy " - another B&W project.

Yours truly
MFTR