QtCreator "Go to slot " - where is SIGNAL?
-
Can anybody suggest reading documentation SPECIFICALLY centered on "go to slot" GUI option?
As the name implies It creates only SLOT function. .
So how does it works when the SIGNAL is not part of the "connect" - actually there in no "connect " in code. -
Can anybody suggest reading documentation SPECIFICALLY centered on "go to slot" GUI option?
As the name implies It creates only SLOT function. .
So how does it works when the SIGNAL is not part of the "connect" - actually there in no "connect " in code.@AnneRanch said:
So how does it works when the SIGNAL is not part of the "connect" - actually there in no "connect " in code.
See QMetaObject::connectSlotsByName and an example here: Widgets and Dialogs with Auto-Connect.
QtCreator's "go to slot" is a ui front for this feature.Basically it looks for slots using certain naming convention and connects them to signals based on that name. The "go to slot" option generates a slot with such name and adds the
QMetaObject::connectSlotsByNamecall in the generatedsetupUifunction. -
Am I correct to say that "go to slot"
actually builds a regular "slot" function of specific format which include "SIGNAL "?void on_<object name>_<signal name>(<signal parameters>);
// generate test TRACE
void TabWidget_Chat::on_pushButton_9_clicked() // TOKIf that is correct , I should be able to bypass my "include" error and build the "slot / signal " function manually.
EDIT
Yes, I can code this "slot/signal" function same as "regular" slot.Now I need to figure out how to "connect" to slot in parent object and pass data to parent - from dialog to widget form.
-
Am I correct to say that "go to slot"
actually builds a regular "slot" function of specific format which include "SIGNAL "?void on_<object name>_<signal name>(<signal parameters>);
// generate test TRACE
void TabWidget_Chat::on_pushButton_9_clicked() // TOKIf that is correct , I should be able to bypass my "include" error and build the "slot / signal " function manually.
EDIT
Yes, I can code this "slot/signal" function same as "regular" slot.Now I need to figure out how to "connect" to slot in parent object and pass data to parent - from dialog to widget form.
@AnneRanch said:
actually builds a regular "slot" function of specific format which include "SIGNAL "?
Yes, it just crates a regular slot and names it in a way the auto-connect feature picks up on.
Now I need to figure out how to "connect" to slot in parent object and pass data to parent
Usually that's not a setup you'd want to go with. A sort of top down pyramid of responsibilities is a way more flexible design i.e. an object would be responsible for contacting its children, but not its parent. So in what you describe it's not a child that would connect to slot in parent but the parent would connect to its child's signal. Such top down branching design is a lot easier to write and maintain. By not reaching up you avoid child including parent code and avoid issues like circular dependencies, that easily get out of control and become difficult to untangle.
-
@AnneRanch said:
actually builds a regular "slot" function of specific format which include "SIGNAL "?
Yes, it just crates a regular slot and names it in a way the auto-connect feature picks up on.
Now I need to figure out how to "connect" to slot in parent object and pass data to parent
Usually that's not a setup you'd want to go with. A sort of top down pyramid of responsibilities is a way more flexible design i.e. an object would be responsible for contacting its children, but not its parent. So in what you describe it's not a child that would connect to slot in parent but the parent would connect to its child's signal. Such top down branching design is a lot easier to write and maintain. By not reaching up you avoid child including parent code and avoid issues like circular dependencies, that easily get out of control and become difficult to untangle.
@Chris-Kawa From some years of experience I just automatically choose to have parent initialize the data inquiry and then have child to send data back when available. Hence "connect" child to parent when data is ready.
I'll try to change that using your approach - seems less prone to confusion, especially when I actually will have two levels of interaction - (area) form (parent ) -> first level (dialog) child -> second level (dialog) child.
. -
@AnneRanch Admittedly it gets muddier the higher in the hierarchy you go, simply because of the scope that needs to be tracked in mind to design this, but it's useful to bring it to basics and build up: A button class doesn't need to implement the logic for a dialog it is in. The dialog doesn't need to implement the main application window logic e.g. when it is shown, created, destroyed or where it gets data from. The main window doesn't need to do the main loop, handle application wide events etc.
Same goes for data structures and passing them between classes - One class creates a data structure, passes it to a "child" object to process it and gets the data back from it. It's not the child that has to worry what spawned it, where the data came from and where it goes, it just exposes some getter and setter methods. It's a worker that does a specific thing on a piece of data it was given.
A good examples of this are the built-in Qt dialog classes like QFileDialog - you create it, give it a starting point and some filters and it gives you back a file path. It doesn't connect to anything in your calling code, it doesn't even know about it. It's the "parent" code that handles the creation of the dialog, connects to its signals, retrieves the data and destroys the dialog when it doesn't need it anymore.
