[squeak-dev] Windows Time millisecondClockValue (system start vs. image start)

Henrik Nergaard henrik.nergaard at uia.no
Sun Aug 7 15:18:45 UTC 2016


Hmm.
ActiveHand lastEvent “"[(798 at 340) mouseOver SHIFT nil nil]"
ActiveHand instVarNamed: #lastEventBuffer "#(1 148008281 659 126 0 0 1 1)" “Timestamp is there, second element”

I cannot see that the stamp is ever 0 from a raw event polled, and I guess that will (should) never happen?
Ie; in HandMorph >> generateMouseEvent: line 15 “stamp = 0 ifTrue: [ stamp := Time milisecondClockValue ]” is dead/wrong code?

So I guess that somewhere along the event dispatching/processing (after he event has been moved from the raw buffer into a MorphicEvent subclass object) things are copied/translated without keeping the original timestamp intact.
I found at least two places that causes the timestamp to be lost:
               MouseEvent >> asMoueMove (sets a new timestamp using Time)
              MouseEvent >> asMouseOver

I think there are two bugs here

1)     VM clock can differ from Image clock

2)     Translating one event from another do not keep the original timestamp

Best regards,
Henrik


From: squeak-dev-bounces at lists.squeakfoundation.org [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On Behalf Of Nicolai Hess
Sent: Sunday, August 7, 2016 3:57 PM
To: Pharo Development List <pharo-dev at lists.pharo.org>; The general-purpose Squeak developers list <squeak-dev at lists.squeakfoundation.org>
Subject: [squeak-dev] Windows Time millisecondClockValue (system start vs. image start)

Hi,
a call to
Time millisecondClockValue
gives the current milliseconds since the image started. Did this change ?
I have a windows squeak 4.4 VM where it gave the uptime of the system (on windows).
Background:
HandMorph generates some MouseOver and/or MouseMove events, and if the
timeStamp value is not set, it sets it to Time millisecondClockValue, but the "real" events have
a time stamp of "milliseconds since system was booted".

So, now it can happen that you have a real event (mouse click) at timeStamp (msecs since boot up)
3000000
and afterwards a generated mouseOver event with a time stamp since image startup
2000000 (if the image started ~15 min after system boot).
That is, a later event as a lower time stamp. This will disturb the event handling in
HandMorph>>#handleEvent: from:
Somehow, (after having the image running for a long time ? I don't know). The time stamp
for the generated events is allways much bigger than for the system events, and this
will make it impossible to detect double-click events.
see issue
https://pharo.fogbugz.com/f/cases/18859
and
http://stackoverflow.com/questions/38700587/double-click-highlight-selection-in-pharo-5-0

thanks
nicolai
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20160807/2170799b/attachment.htm


More information about the Squeak-dev mailing list