Nicolai Hess-3-2 wrote
> 2016-08-07 17:18 GMT+02:00 Henrik Nergaard <

> henrik.nergaard@

> >:
> 
>> 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
>>
> 
> 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.
> 
> 
>>
>>
>> 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 .squeakfoundation

>  [mailto:
>> 

> squeak-dev-bounces at .squeakfoundation

> ] *On Behalf Of *Nicolai Hess
>> *Sent:* Sunday, August 7, 2016 3:57 PM
>> *To:* Pharo Development List <

> pharo-dev at .pharo

> >; 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
>>
>>
>>
>>

Hi Nicolas,

event time stamps have been broken in the Windows VM for a long time. See
here:
http://forum.world.st/win32-Morphic-event-timeStamp-bug-td4824244.html

Best,
Marcel




--
View this message in context: http://forum.world.st/Windows-Time-millisecondClockValue-system-start-vs-image-start-tp4909842p4909869.html
Sent from the Squeak - Dev mailing list archive at Nabble.com.