A Design Issue...

[nupul]

I have this Design issue with my Qt app.

Module 1:
controller.h
controller.cpp
controller_main.cpp

Has 4 buttons.

//signal slots disabled...just display

Module 2:
MyInterface.h
MyInterface.cpp
myinterface_main.cpp

//has signals and slots, w.r.t. the buttons in the interface.

Has 4 interfaces (i.e 4 MyInterface objects), one for each button (w.r.t. module 1)

The two modules were created independently, and thus two "main.cpp" files. This helped us test the working independently.

Now what I am not able to figure out is this:
Without using aggregation (i.e. declaring MyInterface objects in Controller) how do I activate the signals/slots,
s.t. when a button is clicked in Module 1, the Corresponding interface designed in module 2 should be invoked.

ummm I am quite

I'll appreciate your help

Thanks

Nupul

[jacek]

Just connect controller signals to slots of those interfaces.

[Chicken Blood Machine]

I have this Design issue with my Qt app.



The two modules were created independently, and thus two "main.cpp" files. This helped us test the working independently.

Now what I am not able to figure out is this:
Without using aggregation (i.e. declaring MyInterface objects in Controller) how do I activate the signals/slots,
s.t. when a button is clicked in Module 1, the Corresponding interface designed in module 2 should be invoked.

ummm I am quite

I'll appreciate your help

Thanks

Nupul

Connect the two objects together in a single main, e.g:

// Create objects
Controller* c = new Controller(...);
MyInterface* mi = new MyInterface(...);
...
// Connect objects together
QObject::connect(c->button1, SIGNAL(clicked()), mi, SLOT(handleButton1Click()));
QObject::connect(c->button2, SIGNAL(clicked()), mi, SLOT(handleButton2Click()));
...etc.

// Create objects
Controller* c = new Controller(...);
MyInterface* mi = new MyInterface(...);
...
// Connect objects together
QObject::connect(c->button1, SIGNAL(clicked()), mi, SLOT(handleButton1Click()));
QObject::connect(c->button2, SIGNAL(clicked()), mi, SLOT(handleButton2Click()));
...etc.

To copy to clipboard, switch view to plain text mode 

Personally I would make the buttons private members of Controller and capture and re-emit their signals from controller, but that's outside the scope of this problem.

[nupul]

Is the case usually handled like the above code snippet? shouldn't there be a different way for such units to be connected...without using aggregation - so as to not strongly couple a system!!

Nupul

[Chicken Blood Machine]

Where do you see aggregation? I don't see any aggregation.

[nupul]

Where do you see aggregation? I don't see any aggregation.

My mistake...I was referring to aggregation as mentioned in my problem....not in your code - I just mixed two statements into 1

Personally I would make the buttons private members of Controller and capture and re-emit their signals from controller,
but that's outside the scope of this problem.

I don't think it's out of scope. I was hasty in my reply and didn't realise...The buttons of controller are private
to the class! Thus the above solution (your prev reply), won't work...I will have to do what you quoted!

Do I need to capture and re-emit a simple signal like clicked() for each of the 4 buttons? How can I use 1 signal and still be able to do the needful? I'd appreciate even a pseudo-code snippet to better understand this implementation

I feel that your snippet would make the modules highly cohesive - a desirabile trait - I
just want to confirm this with you guys

Thanks

Nupul

[Chicken Blood Machine]

Do I need to capture and re-emit a simple signal like clicked() for each of the 4 buttons? How can I use 1 signal and still be able to do the needful? I'd appreciate even a pseudo-code snippet to better understand this implementation

Generally, you should have a separate signal for each button. Unless the buttons are in a homogenous group and you just want the id/index of the pressed button, then you are better declaring a signal associated with the function of each button.

// Interface
class SaleOrderDialog
{
Q_OBJECT
public :
    SaleOrderDialog(...);
    ...
signals :
    void orderItems();
    void calculateTotal();
    ...
private :
    QPushButton* orderButton;
    QPushButton* totalButton;
};
 
// Implementation
SaleOrderDialog::SaleOrderDialog(...)
{
   ...
 
   // Delegate button clicks to public signals
    connect(orderButton, SIGNAL(clicked()), SIGNAL(orderItems()));
    connect(totalButton, SIGNAL(clicked()), SIGNAL(calculateTotal()));
}

// Interface
class SaleOrderDialog
{
Q_OBJECT
public :
    SaleOrderDialog(...);
    ...
signals :
    void orderItems();
    void calculateTotal();
    ...
private :
    QPushButton* orderButton;
    QPushButton* totalButton;
};

// Implementation
SaleOrderDialog::SaleOrderDialog(...)
{
   ...

   // Delegate button clicks to public signals
    connect(orderButton, SIGNAL(clicked()), SIGNAL(orderItems()));
    connect(totalButton, SIGNAL(clicked()), SIGNAL(calculateTotal()));
}

To copy to clipboard, switch view to plain text mode 

If you follow my example, you will see that the interface of the dialog, declares signals
that describe specific functionality provided by the module and expose nothing about the nature of the GUI inside. You are now free to exchange your push buttons for toolbuttons or other widgets, even change the widget signal that you wish to use to initiate the action (for example toggled() instead of clicked()) without changing the objects connected to this one. Use an intermediate slot if you need to emit a signal with more information (i.e. more parameters). Sometimes you can shorten this step if you use a QSignalMapper.

I hope this addresses your quandaries.