Get QDialog be its title (or name)

Please_Help_me_D

Hi,

Let's suppose that my application has several windows (QDialog) and each of them has its title and other parameters.
How to get any of those QDialogs by their names (titles)?
QDialogs were created with QtDesigner

mrjj

@Please_Help_me_D

How to achieve that?
use signals and slots. define a new signal in ColorBarEditorForm
like
public signals:
void OkPressed(QString data1, QString data2); // amount of data is up to you

Then define a slot in ColorBarWidgetMain with exact same parameters

then in
void ColorBarWidgetMain::mouseDoubleClickEvent
connect OKpressed signal to Okpressed slot in ColorBarWidgetMain

and then
emit OkPressed(ui->LineEdit->Text(), xxxx );
in the ok botton slot.
and it will work like magic.

Why colorBarEditorForm.setParent(this); doesn't do what I want?
As when you set a parent it thinks it should be inside that parent.
is ColorBarEditorForm based on QDialog ?

Kent-Dorfman

Well how do you think you might do that? Try to reason it out.

jsulm

@Please_Help_me_D Did you read documentation? It's there...

Please_Help_me_D

@Kent-Dorfman one possible way is to use parent-child features. I think that could solve my problem.
But just to know is there a way to get a list of all opened QDialog?
EDIT:
I tried to set a parent for the window but this doesn't work. The window now doesnt appear at all. Maybe it is inside the parent widget...

JonB

@Please_Help_me_D

But just to know is there a way to get a list of all opened QDialog?

If you are saying you open your dialog(s) without any parent, you can visit them from https://doc.qt.io/qt-5/qapplication.html#topLevelWidgets, and then obviously look at their titles. There is even https://doc.qt.io/qt-5/qapplication.html#allWidgets to walk all widgets, if that is really what you need (though parentage would be preferable, you shouldn't need this).

Please_Help_me_D

@JonB thank you!
I will keep that in mind.

Now I would like to do this with parentage, it should be the simplest way but It doesn't work.
I have a widget MyWidget and when user double-click it a new window appears NewWindow.
I would like set MyWidget as a parent of NewWindow but new window should appear somewhere on the screen and NOT inside the MyWidget.
So I have:

void ColorBarWidgetMain::mouseDoubleClickEvent(QMouseEvent *event){
    ColorBarEditorForm colorBarEditorForm(nullptr, this);
    colorBarEditorForm.setParent(this);
    colorBarEditorForm.exec();
}

But with the string colorBarEditorForm.setParent(this); the colorBarEditorForm doesn't appear at all.
The idea is to set some properties to the ColorBarWidgetMain when on NewWindow user clicks APPLY-Button. How to achieve that? Why colorBarEditorForm.setParent(this); doesn't do what I want?

mrjj

@Please_Help_me_D

How to achieve that?
use signals and slots. define a new signal in ColorBarEditorForm
like
public signals:
void OkPressed(QString data1, QString data2); // amount of data is up to you

Then define a slot in ColorBarWidgetMain with exact same parameters

then in
void ColorBarWidgetMain::mouseDoubleClickEvent
connect OKpressed signal to Okpressed slot in ColorBarWidgetMain

and then
emit OkPressed(ui->LineEdit->Text(), xxxx );
in the ok botton slot.
and it will work like magic.

Why colorBarEditorForm.setParent(this); doesn't do what I want?
As when you set a parent it thinks it should be inside that parent.
is ColorBarEditorForm based on QDialog ?

Please_Help_me_D

@mrjj thank you!
Now I see. I don't know why I could get this idea with signal and slots by myself, probably I started thinking from wrong starting point :)
Today I will try this solution.

Yes, ColorBarEditorForm is based QDialog, but probably I will change it type to some other because I only today found Windows Flags

mrjj

@Please_Help_me_D
well even im so called experienced, it also took me a while to think in terms of
signals and slot where i would normally have a pointer to "the other class"

But it really is much better as the 2 classed dont even have to know each other and
the slot will have direct access to the UI / widgets which outside pointer will not - so
to send the data via a signal is good design in most cases.

Also you can easily write a test object that you connect to instead and it can automatic send some test data. The ColorBarWidgetMain wont know the difference.
So its a more decoupled Design which is good for maintenance and adding features as nothing breaks even if you change the dialog. it still just have to emit the signal and no other class needs to know about any internal changes.