[Qt-interest] Question regarding QTimer
Anton Chernov
mechernov at gmail.com
Thu Mar 17 14:15:53 CET 2011
And, yep timerEvent in the filter object is the right direction too. :)
Congratulations!
2011/3/17 Vesa Shmuel Peltonen <vesashmuel at gmail.com>
> Thanks all for good input! Problem solved :)
>
> I looked at QToolButton implementation as William suggested, and changed in
> mine implementation QTimer to QBasicTimer. Now timeout event is received
> correctly by the timerEvent function (which I reimplemented in my widget).
> The only think that brothers me, is that what is the difference between
> using QTimer or QBasicTimer, I guess it is related to event queue somehow as
> Atlant said?? Btw, my widget receives very few mouse events (or any events),
> so that does not explain the fact the QTimer timeout is blocked.
>
> cheers,
> vesa
>
> On Thu, Mar 17, 2011 at 1:13 PM, william.crocker at analog.com <
> william.crocker at analog.com> wrote:
>
>>
>> >
>> > I'm sorry, but I didn't get your point. I'm receiving the mouse event
>> > fine to the widget that I want them, and I'm handling those and not
>> > propagating these events further. The problem that I'm facing is when
>> > user press mouse for long time inside the widget, I want to do something
>> > before user releases the mouse. The 1st thing that came to my mind, is
>> > to use Qtimer, and do the thing after timeout occurs, but the slot is
>> > called always only after the mouse is released. Are you suggesting,
>> > that the timer behavior will be affected if events are propagated or
>> > something on that path?
>> >
>> > Any other ideas how to achieve the functionality? I.e to do something
>> > after user holds mouse for certain time (without releasing it).
>> >
>>
>> Why don't you investigate how *this* is implemented (and I quote) :
>>
>> QToolButton::DelayedPopup
>>
>> After pressing and holding the tool button down for a certain amount of
>> time (the timeout is style dependent, see
>> QStyle::SH_ToolButton_PopupDelay), the menu is displayed. A typical
>> application example is the "back" button in some web browsers's
>> tool bars. If the user clicks it, the browser simply browses back to the
>> previous page. If the user presses and holds the button
>> down for a while, the tool button shows a menu containing the current
>> history list
>>
>> > Thanks,
>> > vesa
>> >
>> > On Thu, Mar 17, 2011 at 12:18 PM, Anton Chernov <mechernov at gmail.com
>> > <mailto:mechernov at gmail.com>> wrote:
>> >
>> > Ok, here are the highlights:
>> >
>> > > Qt automatically grabs the mouse when a mouse button is pressed
>> > inside a widget; the widget will continue to receive mouse events
>> > until the last mouse button is released. A mouse event contains a
>> > special accept flag that indicates whether the receiver wants the
>> > event. *You should call ignore() if the mouse event is not handled
>> > by your widget.*
>> > *Make sure you call ignore in the custom widget. (Or
>> QWidget::event() )
>> > *
>> > *
>> > *
>> > > Qt::WA_NoMousePropagation. *Schould be off!*
>> > *
>> > *
>> > But if the worst case is the following:*
>> > *
>> > > If you create new widgets in the mousePressEvent() the
>> > mouseReleaseEvent() may not end up where you expect, depending on
>> > the underlying window system (or X11 window manager), the widgets'
>> > location and maybe more.
>> > Then maybe its worth reporting a bug.
>> >
>> >
>> > 2011/3/17 Vesa Shmuel Peltonen <vesashmuel at gmail.com
>> > <mailto:vesashmuel at gmail.com>>
>> >
>> > Thanks guys for your help so far!
>> >
>> > I'm checking the relevant object in the filter, and the filter
>> > is installed on a custom Qwidget.
>> >
>> > Here are the relevant traces. As you can see, the timer slot is
>> > called only after the mouse is released. The timeout probably
>> > has happened before that, because it is called immediately after
>> > mouse release event (when non zero timeout is used).
>> >
>> > [Qt Message] eventFilter: IN
>> > [Qt Message] eventFilter: mouse press
>> > [Qt Message] starting longpress timer with 0 timeout
>> > [Qt Message] eventFilter: OUT
>> >
>> > [Qt Message] eventFilter: IN
>> > [Qt Message] eventFilter: mouse move
>> > [Qt Message] eventFilter: OUT
>> >
>> > [Qt Message] eventFilter: IN
>> > [Qt Message] eventFilter: mouse move
>> > [Qt Message] eventFilter: OUT
>> >
>> > [Qt Message] eventFilter: IN
>> > [Qt Message] eventFilter: mouse move
>> > [Qt Message] eventFilter: OUT
>> >
>> > [Qt Message] eventFilter: IN
>> > [Qt Message] eventFilter: mouse release
>> > [Qt Message] eventFilter: OUT
>> >
>> > [Qt Message] longPressTimeOutSlot IN
>> >
>> >
>> > On Wed, Mar 16, 2011 at 6:43 PM, Anton Chernov
>> > <mechernov at gmail.com <mailto:mechernov at gmail.com>> wrote:
>> >
>> > Where is you filter installed? Make sure this widget gets
>> > the events.
>> >
>> > By the way I would check if this is the right object in the
>> > params (*object) ... :) Installing this filter on qApp will
>> > cause you hell :)
>> >
>> > 2011/3/16 Vesa Shmuel Peltonen <vesashmuel at gmail.com
>> > <mailto:vesashmuel at gmail.com>>
>> >
>> > Yes, I know :)
>> > The timer is started only once, when mouse is pressed. I
>> > expected, that the timer will timeout after 150 ms even
>> > when the mouse is still down, but it is not.
>> > So, the sequence is this:
>> > 1. Mouse press down
>> > -> timer started (I tried even 0 with timeout)
>> > 2. Mouse hold down for long time
>> > 3. Mouse released
>> > => timeout slot is called only here (even with 0
>> timeout).
>> >
>> > As I said, tried this only on S^3, maybe platform
>> > specific behavior?
>> >
>> > Thanks again,
>> > Vesa
>> >
>> >
>> > On Wed, Mar 16, 2011 at 5:16 PM, Atlant Schmidt
>> > <aschmidt at dekaresearch.com
>> > <mailto:aschmidt at dekaresearch.com>> wrote:
>> >
>> > Vesa:
>> >
>> >
>> >
>> > You know that QTimers are “retriggerable”, right?
>> > That is,
>> > if you do an m_timer->start(150) multiple times,
>> each
>> > within 150 ms of the previous one, the timer
>> > doesn’t time-out
>> > until 150 ms after the **LAST** call to start().
>> >
>> > Perhaps you’re getting more MouseButtonPress
>> events
>> > than you think and they’re re-triggering your
>> > timer? Maybe
>> > you can place some debugging print or some such in
>> the
>> > path that start()s the timer?
>> >
>> >
>> >
>> > Atlant
>> >
>> >
>> >
>> >
>> ------------------------------------------------------------------------
>> >
>> > *From:*
>> > qt-interest-bounces+aschmidt=dekaresearch.com
>> > <http://dekaresearch.com>@qt.nokia.com
>> > <http://qt.nokia.com>
>> > [mailto:qt-interest-bounces+aschmidt
>> > <mailto:qt-interest-bounces%2Baschmidt>=
>> dekaresearch.com
>> > <http://dekaresearch.com>@qt.nokia.com
>> > <http://qt.nokia.com>] *On Behalf Of *Vesa Shmuel
>> > Peltonen
>> > *Sent:* Wednesday, March 16, 2011 10:39
>> > *To:* qt-interest at qt.nokia.com
>> > <mailto:qt-interest at qt.nokia.com>
>> > *Subject:* [Qt-interest] Question regarding QTimer
>> >
>> >
>> >
>> > Hello all,
>> >
>> >
>> >
>> > I've simple question. I'm trying to start a timer
>> > when mouse press event is received on eventfilter:
>> >
>> >
>> >
>> > xxx::eventFilter(QObject *object, QEvent *event)
>> >
>> > {
>> >
>> >
>> >
>> > if ( event->type() == QEvent::MouseButtonPress )
>> >
>> > {
>> >
>> >
>> >
>> > m_timer->start(150); // msec
>> >
>> > ...
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > It seems that the timer timeouts always only after
>> the mouse is released, even if the mouse press is very long (many seconds).
>> >
>> > Is this known behavior and is there way to overcome
>> the problem? Is the system process blocking the application thread during
>> the mouse press, so even if the timeout should have happen much earlier, the
>> slot is called only after the mouse is released?
>> >
>> > Btw, my environment is Qt 4.7.2 on *S^3 device*.
>> I've not tested the behavior on other platforms.
>> >
>> >
>> >
>> >
>> >
>> > Thanks,
>> >
>> > Vesa
>> >
>> >
>> >
>> > Click here
>> > <
>> https://www.mailcontrol.com/sr/xVgY2I1OSnbTndxI!oX7UiNQo6b55PW6E6Mk6PJ6lylK0Gxzl8M9JqgO7Csb+Br3JfPdjQoD3dvZM0Vr2cPI!w==
>> >
>> > to report this email as spam.
>> >
>> >
>> >
>> ------------------------------------------------------------------------
>> > This e-mail and the information, including any
>> > attachments, it contains are intended to be a
>> > confidential communication only to the person or
>> > entity to whom it is addressed and may contain
>> > information that is privileged. If the reader of
>> > this message is not the intended recipient, you are
>> > hereby notified that any dissemination, distribution
>> > or copying of this communication is strictly
>> > prohibited. If you have received this communication
>> > in error, please immediately notify the sender and
>> > destroy the original message.
>> >
>> > Thank you.
>> >
>> > Please consider the environment before printing this
>> > email.
>> >
>> >
>> >
>> > _______________________________________________
>> > Qt-interest mailing list
>> > Qt-interest at qt.nokia.com <mailto:
>> Qt-interest at qt.nokia.com>
>> > http://lists.qt.nokia.com/mailman/listinfo/qt-interest
>> >
>> >
>> >
>> >
>> >
>> >
>> > ------------------------------------------------------------------------
>> >
>> > _______________________________________________
>> > Qt-interest mailing list
>> > Qt-interest at qt.nokia.com
>> > http://lists.qt.nokia.com/mailman/listinfo/qt-interest
>> _______________________________________________
>> Qt-interest mailing list
>> Qt-interest at qt.nokia.com
>> http://lists.qt.nokia.com/mailman/listinfo/qt-interest
>>
>
>
> _______________________________________________
> Qt-interest mailing list
> Qt-interest at qt.nokia.com
> http://lists.qt.nokia.com/mailman/listinfo/qt-interest
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20110317/f4ac3bd6/attachment.html
More information about the Qt-interest-old
mailing list