Windows Time millisecondClockValue (system start vs. image start)
Locked
Windows Time millisecondClockValue (system start vs. image start)
 
|
Hi, a call to 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. |
Re: [squeak-dev] Windows Time millisecondClockValue (system start vs. image start)
|
|
Hmm. ActiveHand lastEvent “"[(798@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: [hidden email] [mailto:[hidden email]]
On Behalf Of Nicolai Hess 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".
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 thanks nicolai |
Re: [squeak-dev] Windows Time millisecondClockValue (system start vs. image start)
|
|
2016-08-07 17:18 GMT+02:00 Henrik Nergaard <[hidden email]>:
Yes, that is what I meant by generating mousemove/mouseover events. For example, if you put Transcript show:{ evt type. evt timeStamp . firstClickTime} ;cr. at top of method handleEvent:from: and click (just click no movement) on the title pane of a system window, you'll see a alot of #(#mouseMove 9128631 12518171) Transcript entries The entries look like they are new events, but I think they are just generated from the last real event , but with a new time stamp.
|
| Free forum by Nabble | Edit this page |