No such signal...

[chaimar]

Hello,
I have a little problem with connecting a signal to a slot.


I try doing this:

QObject::connect(tbl,SIGNAL(clicked(int,int,int,co nst QPoint&)),this,SLOT(registerDblKlikket(int,int,int ,const QPoint&)));

this is happening inside a slot, so this connection is only supposed to be active under certain circumstances. I don't get an compile-time error, but when the slot where this connection is, is activated I get the following messages in the debug window:

QObject::connect: No such signal QWidget::clicked(int,int,int,const QPoint&)
QObject::connect: (sender name: 'tbl')
QObject::connect: (receiver name: 'MainForm')

I can't see whats wrong, there is indeed a signal called clicked(...), but why is it complaining about QWidget::clicked(...). Is there something wrong
with the sender, tbl
It is a QTable.

Can someone help me?

[jacek]

Try adding #include <qtable.h> at the beginning of a file with that connect statement.

[chaimar]

Try adding #include <qtable.h> at the beginning of a file with that connect statement.

Thanks, but that didn't work.
I made this file with the designer and I have a default QTable in a widgetstack.
When the right things happens that default table is set by another table like this:

tbl = (QTable *)_rs.reg("string","string");

reg(...) is returning an object which inherit QTable, hence the casting.
I then set the name for tbl:

tbl->setName("tbl");

Then I connect the tbl and remove the default page in the widgetstack and add the tbl, like this:

_widStack->removeWidget(_widStack->widget(2));
_widStack->addWidget(tbl,2);
_widgStack->raiseWidget(tbl);

Can you see something wrong about this - is there something I'm missing?

Chaimar...

[seneca]

Try using only "QPoint" within the SIGNAL/SLOT macros instead of "const QPoint&". Those decorations are not needed there, only the plain type.

[jacek]

Could you post the line in which you declare that tbl variable?

[wysota]

QObject::connect(tbl,SIGNAL(clicked(int,int,int,co nst QPoint&)),this,SLOT(registerDblKlikket(int,int,int ,const QPoint&)));

Isn't there a space in "const" in the signal signature? And be sure you have that qtable.h included.

BTW. The "decorations" are important :)

[Chicken Blood Machine]

Isn't there a space in "const" in the signal signature? And be sure you have that qtable.h included.

BTW. The "decorations" are important

The header qtable.h need not be included unless you call methods of QTable somewhere else in the file. You're right about the co nst though.

[chaimar]

wysota: I didn't use copy-paste on that sentence, there's no space in the code. My mistake
I have included the qtable.h too.
seneca:I tried using just QPoint, but it didn't make any difference.

Here's the declaration of the tbl, which the designer has made:
tbl = new QTable( privateLayoutWidget_2, "tbl" );
tbl->setSizePolicy( QSizePolicy( (QSizePolicy::SizeType)0, (QSizePolicy::SizeType)0,0, 0, tbl->sizePolicy().hasHeightForWidth() ) );
tbl->setMinimumSize( QSize( 1150, 330 ) );
tbl->setMaximumSize( QSize( 1450, 750 ) );
tbl->setNumRows( 3 );
tbl->setNumCols( 12 );

next part where something happens to the tbl is, like I mentioned earlier today:

I made this file with the designer and I have a default QTable in a widgetstack.
When the right things happens that default table is set by another table like this:
tbl = (QTable *)_rs.reg("string","string");
reg(...) is returning an object which inherit QTable, hence the casting.
I then set the name for tbl:
tbl->setName("tbl");
Then I connect the tbl and remove the default page in the widgetstack and add the tbl, like this:
_widStack->removeWidget(_widStack->widget(2));
_widStack->addWidget(tbl,2);
_widgStack->raiseWidget(tbl);

I've made a similar signal-slot call in designer with another table in this file and it is name-similar slot, could that cause any problem?

[wysota]

The header qtable.h need not be included unless you call methods of QTable somewhere else in the file.

There is one more situation when the header file is needed -- to check if the class inherits some other class, for example:

connect(someclass, SIGNAL(x()), this, SLOT(y)));

connect(someclass, SIGNAL(x()), this, SLOT(y)));

To copy to clipboard, switch view to plain text mode 

The header file for "someclass" is needed for the compiler to see if it inherits QObject.

[jacek]

tbl = (QTable *)_rs.reg("string","string");

Are you sure that this returns a QTable object?

What does this print?

tbl = (QTable *)_rs.reg("string","string");
qDebug( "tbl is a %s", tbl->className() );

tbl = (QTable *)_rs.reg("string","string");
qDebug( "tbl is a %s", tbl->className() );

To copy to clipboard, switch view to plain text mode 

[chaimar]

jacek wrote:

Are you sure that this returns a QTable object?

I'm so sorry, I'm very, very sorry .
Big mistake here, I tried to write out the classname as you said jacek, and it seemed that, what I thougt was a QTable, returned a QWidget.
Damn it, I'm mad at myself...
Jacek and wysota, I'm truly sorry that I took up your time with this bad thread, but thank you anyway. I'm might be wandering in the darkness for a long time otherwise.
Well it returned a QWidget and the main widget in that class is a QTable and thats the table I really want.
Do you guys have any idea how I should accomplish this. There is obvious no use casting it to a QTable like I did:

tbl = (QTable *)_rs.reg("string","string");

I can of course try to return just the table I want
I write before I think.
Thank you very much guys, I will search my code an extra time before I next time send a question.

Yours sincerely
Chaimar

[Chicken Blood Machine]

There is one more situation when the header file is needed -- to check if the class inherits some other class, for example:

connect(someclass, SIGNAL(x()), this, SLOT(y)));

connect(someclass, SIGNAL(x()), this, SLOT(y)));

To copy to clipboard, switch view to plain text mode 

The header file for "someclass" is needed for the compiler to see if it inherits QObject.

Good point, yes you're right.

[wysota]

jacek wrote:
Jacek and wysota, I'm truly sorry that I took up your time with this bad thread, but thank you anyway. I'm might be wandering in the darkness for a long time otherwise.

(...)

Thank you very much guys, I will search my code an extra time before I next time send a question.

Don't worry, it is most important that you learnt something from it and that you know what the problem was. We don't consider time spent on your question wasted. We're here to answer questions, right?