Difficult connect of signals and slots

[Ozzy]

Hi,

I am working on a project and have some serious problems concerning the connections and slots through my project. Let me explain this to you:
I have a MainForm that contains some widgets that are promoted to other forms (to split my gui into several classes).
In addition I have a thread that shall update the gui. The thread is started in the constructor of the MainForm. Therefor I think I have to do the connect in the constructor, too. But how can I connect the thread signal through the promoted widgets to the wanted slot?

Thanks and best regards
Ozzy

[stampede]

In addition I have a thread that shall update the gui

Why do you need that ? Could be easier to help if you show us some code.

[anda_skoa]

Additional to what stampede already said, you can access your widgets through the ui pointer, no matter if they are promoted or not

connect(someSource, SIGNAL(someSignal()), ui->somePromotedWidget, SLOT(someSlot()));

connect(someSource, SIGNAL(someSignal()), ui->somePromotedWidget, SLOT(someSlot()));

To copy to clipboard, switch view to plain text mode 

Cheers,
_

[Ozzy]

Hi,

thats right. But from default, the ui is private. The question is whether it is useful to change all needed ui-objects to public...

[anda_skoa]

Even if it is private, you are doing that in the very samel class' constructor. It can access its own private members

No need to make anything public.

Cheers,
_

[Ozzy]

Hi,

sorry, but I don't get it. Suppose I have a very nested design where the mainFrame has a widget that is promoted (by the designer) to another form (in this case form with a QFrame template). This form contains several widget including a widget that is also a form with a QFrame template. In this form I want to change the text of a label. So, how can I achieve this? My problem is how to connect the signal of the thread (easy) with the slot in the "last" frame widget.

[anda_skoa]

I am not quite sure I understand the problem.

Lets say you have a custom widget MyWidget and in your MainForm you have that as a child (promoted in designer).
So you can access the MyWidget instance something like this

ui->myWidget

ui->myWidget

To copy to clipboard, switch view to plain text mode 

MyWidget has, as an implementation details, a label and you want to set its text. Since the label is a internal detal of MyWidget and this encapsulated in MyWidget, you need a way to access it through the MyWidget API (see basic OOP principles).

void MyWidget::setText(const QString &text)
{
    // set text on label
}

void MyWidget::setText(const QString &text)
{
    // set text on label
}

To copy to clipboard, switch view to plain text mode 

You can make that a slot and connect to it from MainForm

connect(someSource, SIGNAL(someSignal(QString)), ui->myWidget, SLOT(setText(QString)));

connect(someSource, SIGNAL(someSignal(QString)), ui->myWidget, SLOT(setText(QString)));

To copy to clipboard, switch view to plain text mode 

Cheers,
_

[Ozzy]

Hi,

thank you very much for your reply! Now I got it working. The main problem was that the ui_widget1.h (created by the designer) was included in the .cpp file. So I could not find the widget in the mainFrame. Now I included it in the header file, defined the MainFrame as friend class ( to get access to the private ui) and everything works fine :-)

[anda_skoa]

That is definitely not how it is supposed to be used, but if it works for you who are we to argue

Cheers,
_

[Ozzy]

Hi, but what do you do if you want to access a slot that is in a widget that is promoted to the first widget? So this would be ui->myWidget->ui->myWidget2... Or how do you access this slot?

[anda_skoa]

I answered that already, did I not? Comment #7

The MainForm is dealing with MyWidget, it doesn't and should know about anything that is internal to MyWidget.

Like, if you want to set the value of a QSpinBox, do you need to know that there is a QLineEdit inside QSpinBox, do you need to access it? Why not?

Cheers,
_

[Ozzy]

Ok, I think I get your point. So I call a function in the first widget that calls again a function in the next widget, right? So everything keeps private and is only accessible through the 'direct' interfaces.

[anda_skoa]

Yes, exactly.

Each widget is an encapsulated unit. If that unit is in fact composed of other units then this is not "visible" from outside the widget.

Cheers,
_

[Ozzy]

Ok, thank you very much!