[SOLVED] QTimer need stop without signal
-
Of course, it doesn't work, as the timer never started ;-)
[quote author="Gourmand" date="1339517710"]
then if I need stop timer but not to call slot on stop - should this work?@
timer.stop();
@Qt4.7 used[/quote]
Note that, singleShot is a static member of class QTimer, it has no-relationship with the object timer.
Seem what you need is
@
QTimer::setSingleShot()
@ -
Actually, a timer did get started. Calling
@
timer.singleShot(...)
@will call the static function singleShot(), and after 5000 msecs, the signal will be sent. But it won't be your timer object that sends it, but an anonymous timer created by singleShot(). This is why calling stop() on the timer object does not work. You need to set the properties on timer (singleshot, the timeout), connect to it's timeout signal, and then call start() on timer.
-
Yup, so this needs to be done:
@
timer.setSingleshot(true);
connect(timer, SIGNAL(timeout()), this, SLOT(loading()));
timer->start(5000);
@ Have fun ;-) -
[quote author="miroslav" date="1339654187"]Actually, a timer did get started. Calling
@
timer.singleShot(...)
@will call the static function singleShot(), and after 5000 msecs, the signal will be sent. But it won't be your timer object that sends it, but an anonymous timer created by singleShot(). This is why calling stop() on the timer object does not work. You need to set the properties on timer (singleshot, the timeout), connect to it's timeout signal, and then call start() on timer. [/quote]
Of course this explains strange behavior of timer after stop()! But PLEASE point me to documentation where it is clearly written that after timer::singleShot() actually ANOTHER timer sends signal after timeout and stop does not actually work. PLEASE! If this is written - than I just did not read carefully. If it is NOT written - then this is just another one fault in Qt documentation.
-
[quote author="Gourmand" date="1339658356"]Of course this explains strange behavior of timer after stop()! But PLEASE point me to documentation where it is clearly written that after timer::singleShot() actually ANOTHER timer sends signal after timeout and stop does not actually work. PLEASE! If this is written - than I just did not read carefully. If it is NOT written - then this is just another one fault in Qt documentation. [/quote]
The actual problem is that you are calling a "static":http://qt-project.org/doc/qt-4.8/qtimer.html#static-public-members member method (which are indicated by <code>[static]</code> in the "documentation":http://qt-project.org/doc/qt-4.8/qtimer.html#singleShot) on an object, and a static member has no access to the object is has been called on (no this).
Although using the dot operator <code>timer.singleShot(...)</code> is valid C++, it is quite misleading, as you have to be aware of that your are not calling a member function, but rather a static member function. Using the scope resolution operator <code>QTimer::singleShot(...)</code> usually illustrates this.
If you've found a fault in the Qt documentation (although it technically isn't in this case), feel free to file a "bug report":https://bugreports.qt-project.org/secure/Dashboard.jspa. Suggestions for improvements, possibly in the form of a "doc note":http://qt-project.org/blog/view/doc-notes-we-have-a-vision are welcome as well.
-
[quote author="Lukas Geyer" date="1339660191"]
The actual problem is that you are calling a "static":http://qt-project.org/doc/qt-4.8/qtimer.html#static-public-members member method (which are indicated by <code>[static]</code> in the "documentation":http://qt-project.org/doc/qt-4.8/qtimer.html#singleShot) on an object, and a static member has no access to the object is has been called on (no this).
[/quote]But the QTimer is incapsulated and I do not know how it works inside and which data are not accessible by static singleShot(). I can assume that singleShot() calls some non-static private members to make this timer possible to stop(). I just read documentation how to use classes - but I do not analyze how they work in source code... This is C++ with incapsulation, isn't it?
After tens of years od software development I know this truth: if something can mislead then this must be explained in docs quite clear.
-
If you look into Qt Open Source Code, QTimer::singleShot() creates another timer instance of QSingleShotTimer which is internal to the file. Basically this QSingleShotTimer is derived from QObject and it connects the signal and slot and also starts the timer thru QObject::startTimer().
timerEvent() is also overridden inside this QSingleShotTimer, so that once timer is timed out, timer created (inside QSingleShotTimer) will be deleted.
Having said that QTimer::singleShot() will create its own timer and will not access any members of the object that is called on as you have done i.e., timer.singleShot() won't access any timer members.
By going thru the document also,
@void QTimer::singleShot ( int msec, QObject * receiver, const char * member ) [static]@
This static function calls a slot after a given time interval.
It is very convenient to use this function because you do not need to bother with a timerEvent or create a local QTimer object.
It says that singleShot() static member is convenient one as a local QTimer object need not be created.
-
[quote author="Gourmand" date="1339660973"]I do not know how it works inside and which data are not accessible by static singleShot(). I can assume that singleShot() calls some non-static private members to make this timer possible to stop().[/quote]
No. Be aware that in C++ a static member function does not have access to the calling object and its non-static members and non-static member functions, as both require an implicit this pointer (which is non-existent for static member functions, as long as you do not provide it explicitly).If QTimer::singleShot() would depend on (or modify) the calling object, it would not be static.
[quote author="Gourmand" date="1339660973"]if something can mislead then this must be explained in docs quite clear.[/quote]You are right. I don't think it is misleading in this case, because of the member beeing static and no explicit reference to an object beeing passed it is quite clear that it will not (or can not) depend on the calling object.
But as said, feel free to file a suggestion to the bug tracker or add a doc note on your own.
-
Well, it looks pretty clear to me and when reading the documentation carefully with a clear C++ education not misleading at all. Still, feel free to make a suggestion to the bug tracker. Maybe they will update the documentation.
