Slots with additional arguments


i’m trying to use slots with parameters:

void ReveBrowser::BPressed(Int_t idx)
{ printf(“BPressed idx=%d\n”, idx); }
TGTextButton* b = …;
b->Connect(“Pressed()”, “ReveBrowser”, this, Form(“BPressed(=%d)”, i));

This works fine. Now i’d like to have the same thing for signals which already have a parameter, like:

void ReveBrowser::BToggled(Bool_t state, Int_t idx)
{ printf(“BToggled %d idx=%d\n”, state, idx); }
TGCheckButton* b = …;
b->Connect(“Toggled(Bool_t)”, “ReveBrowser”, this, Form(“BToggled(Bool_t,=%d)”, i));

This does not work … seems that the “=” eats up all previous arguments:
Error in TQObject::CheckConnectArgs: slot ReveBrowser::BToggled( 1074) does not exist

Is there a way to get this working or should i use TGWidget::SetCommand and use UserData to pass over the required information?


Hi Matevz,

What is the goal of having different values for your slot parameter? Please provide more details about the purpose of the slot methods BPressed(Int_t idx) and BToggled(Bool_t, Int_t idx) connected to the text and check buttons (‘b’).

Thank you, Ilka


Imagine an object browser where you display a button for each object in current directory. Then one could connect all these buttons to the browser itself and use the additional parameter to identify which one was actually pressed (the browser already knows all the objects and might want to perform additional actions). In real life there would be a set of widgets for each object, including valuators and text entries and one would actually pass two parameters: object and column id.

I went through the code of TQObject and TQConnection and it seems that it would be very hard to implement the generalization i was trying to use before.

I guess the right way is to have a dedicated class for handling browser-object events (having pointers to the object and to the browser). Then one instantiates one object for each browser-object and connects it to the signal. But this can easily lead to a cross-reference bloat … must think some more.

Will let you know if i come up with some smart idea.


Hi Matevz,

There is a way for recognizing (filtering) who is sending the signal in the slot method. For example, if you are looking for signals sent from buttons, you can do:

TGButton *btn = (TGButton *) gTQSender; id = btn->WidgetId(); switch (id) { ... }
Normally the widget id is a parameter of the constructor.

Best regards, Ilka

Hi Ilka!

Great … this will help a lot! I can then use TGWidget’s fUserData member to store additional information.