Implemented a simple fix for the message-pile-up problem of

BView::GetMouse( , ,useHistory = true) in case the application
calls GetMouse() in a loop with a longer delay then mouse
messages arrive at the queue. The "when" field of the messages
is used to discard old mouse moved messages. This also fixes
the possible problem of finding the same message over and over
in case it is not removed from the queue for other reasons.
This fix makes selecting text in Pe for example usable.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26337 a95241bf-73f2-0310-859d-f6bbb57e9c96
This commit is contained in:
Stephan Aßmus 2008-07-09 10:03:28 +00:00
parent 74d5c1e499
commit fe3d5b3083

View File

@ -1410,6 +1410,30 @@ BView::GetMouse(BPoint *location, uint32 *buttons, bool checkMessageQueue)
if (!Window()->_StealMouseMessage(message, deleteMessage))
continue;
if (message->what == B_MOUSE_MOVED) {
// Check if the message is too old. Some applications
// check the message queue in such a way that mouse
// messages *must* pile up. This check makes them work
// as intended, although these applications could simply
// use the version of BView::GetMouse() that does not
// check the history. Also note that it isn't a problem
// to delete the message in case there is not a newer
// one. If we don't find a message in the queue, we will
// just fall back to asking the app_sever directly. So
// the imposed delay will not be a problem on slower
// computers. This check also prevents another problem,
// when the message that we use is *not* removed from
// the queue. Subsequent calls to GetMouse() would find
// this message over and over!
bigtime_t eventTime;
if (message->FindInt64("when", &eventTime) == B_OK
&& system_time() - eventTime > 10000) {
// just discard the message
if (deleteMessage)
delete message;
continue;
}
}
message->FindPoint("screen_where", location);
message->FindInt32("buttons", (int32 *)buttons);
queue->Unlock();