Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | Lars Gullik Bjønnes wrote:
| > | > [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| > | > | I'll see what I can do...
| > | > | (See... I am actually prepared to go the extra mile to please you)
| > | > I am trying to figure out a way so that a comment is not needed.
| > | > Would been nice if qt signals had a <signal>.emit(...) thingie... but
| > | > I am pretty sure it doesn't.
| > | | Me too, they are too pragmatic for that.
| > | | > A macro solution could be used, but is not nice.... #define
| > Q_EMIT
| > | > (As long as qt itself does not define this, we are free to do so...)
| > | | Would be OK but a comment will do fine also and will motivate the
| > | developer to put some more comment as to who this signal emission is
| > | aimed if any.
| > | | // send the Qt signal...
| > | valueChanged();
| > But that documentation about the signal should be put on the signal
| > declaration in the header/class.
|
| No because, depending on where you emit the signal your are targetting
| this or that slot in particular.
But this is instances of signals, so you are emitting the signals in
the instance of the class that you are in. That is the whole point is
it not, the signal should not care or bother which slot will be called
as a result of a emmit.
--
Lgb
