> On 11-01-2016, at 4:41 PM, tim Rowledge <tim at rowledge.org> wrote:
> 

> So I guess somewhere an event is being made with the microsecond time value, or possibly, junk.

Almost - when we fake up a MouseMoveEvent via MouseEvent>asMouseMove, it has been sticking in Time millisecondClockValue as the timeStamp in the belief that the vm will be using the same kind of value. However, now that a 64 bit value is being used for Time millisecondClockValue with no setting to a baseline, that is a poor assumption.

I can fix it (badly) by re-using the timestamp from the event we are converting/faking but that can’t be a long term solution since the entire point is to have an event with the current time get handled and cause any *appropriate* timeouts to happen. I think we still need access to the old millisecond value here?

There are other places where this might cause problems; for example HandMorph>generateMouseEvent where we fake the timestamp if the incoming event has no value set. There’s a possible issue in any case where XXXEvent>type:readFrom: is used. EventRecorderMorph>resumeRecordIn: will do nasty. HandMorph>generateWindowEvent: might. Oh and HandMorph>generateKeyboardEvent:

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Fractured Idiom:- APRES MOE LE DELUGE - Larry and Curly get wet