Slots connection !

[agent007se]

Hi all ! I'm having some troubles with connecting a comboBox and a function...

in .h


private slots:
/*! Call a quit function. */
void slotQuit();

/*! Call a function which can show an AboutForm. */
void slotAbout();

/*! Call a function which update the view when the comboBox is changed. */
void slotCurrentSelectionChanged();


in .cpp


ui_murefImpl::ui_murefImpl(QWidget *parent) : QMainWindow(parent)
{
// configuring the GUI
ui.setupUi(this);
// do connections
connect(ui.actionQuit, SIGNAL(activated()), this, SLOT(slotQuit()));
connect(ui.actionAbout, SIGNAL(activated()), this, SLOT(slotAbout()));
connect(ui.comboBox, SIGNAL(activated(QString test)), this, SLOT(slotCurrentSelectionChanged()));
// end
}

// some code here...

void ui_murefImpl::slotCurrentSelectionChanged()
{
QMessageBox::information(0, "", "ok");
CLinkGUI::callCurrentSelectionChanged();
}



By default I put 2 items in the comboBox... so that I can select them but I never saw the message box with ok... :eek: :eek: :eek:

(of course, the code compile fine... AND others slots function...)

Thanks a lot for the one who find out the solution :D.

edit: Oh, yeah, of course too, with the Designer I can add lower() function as a slot and it work perfectly...


QObject::connect(comboBox, SIGNAL(activated(QString)), MainWindow, SLOT(lower()));

this line is added in ui_muref.h (generated from uic/moc tools)

[jacek]

connect(ui.comboBox, SIGNAL(activated(QString test)), this, SLOT(slotCurrentSelectionChanged()));

You can't put parameter names in SIGNAL and SLOT macros.

[agent007se]

Correct ! Just saw it but I thank you anyway because of your high speed replies :p !

[mikro]

and actually you shouldn't even have a parameter at all in the signal when the slot doesn't receive one - but as long as the signal has more parameters than the slot and not vice versa it will work nevertheless.

[wysota]

and actually you shouldn't even have a parameter at all in the signal when the slot doesn't receive one

Hmm... Why not?

[mikro]

because it's ugly :)
but as i said it works nevertheless, it just might become confusing

[wysota]

because it's ugly :)
Ugly? Why? Are default parameters ugly? Would it be better (less ugly) to have additional, completely redundant slot parameters just to have the same number of parameters as the signal?



but as i said it works nevertheless
Why shouldn't it work? It's behaving according to C++ specification, there is no hack in it.


it just might become confusing
Again, why confusing? You specify output (SIGNAL) and input (SLOT or other SIGNAL) parameters as separate groups (using different macros). I don't see anything confusing about it.