2016-08-07 18:13 GMT+02:00 marcel.taeumel <Marcel.Taeumel at hpi.de>:

> Nicolai Hess-3-2 wrote
> > 2016-08-07 17:18 GMT+02:00 Henrik Nergaard &lt;
>
> > henrik.nergaard@
>
> > &gt;:
> >
> >> 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 &lt;
>
> > pharo-dev at .pharo
>
> > &gt;; The
> >> general-purpose Squeak developers list &lt;squeak-dev at lists.
> > &gt; 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
>
>
Hi, Marcel, yes I saw that thread, we should *bump* it again. You solution
was to modify the event time stamp to use the same
milliseconds-since-image-start, right?

I too was confused about the ioMSecs implementation in sqWin32Windows with
timeGetTime() vs. the one from sqWin32Heartbeat.c
It seems the windows vm uses the one from the heartbeat, but I couldn't
find where this was set, did you find it out?


>
>
>
> --
> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20160808/244a3245/attachment.htm