Double-click gone missing?

It looks like something has stopped double-clicking working in my update 15557 image, whether running on a very latest vm or a slightly older one. D-clicks are quite important in Scratch and I have a big release coming up at the end of the week...

Simplest way to check is to open a ClickExerciserMorph; even browse it and stick a break on the doubleClick: method. The click: and doubleClickTimeout: methods are being hit. I get no hits on doubleClick: at all but there are spurious hits on doubleClickTimeout: when I try to d-click. In fact I get a doubleCLickTimeout: simply by doing a click or click-hold-no-movement (don’t want to trigger a drag). That really isn’t right.

I can’t see any code that relates to MouseClickState has changed recently, though of course we have a big change in Time recently.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Computer Science: solving today's problems tomorrow.

> On 11-01-2016, at 4:15 PM, tim Rowledge <[hidden email]> wrote:
> I can’t see any code that relates to MouseClickState has changed recently, though of course we have a big change in Time recently.

Yeah, if my trapping is returning anything like the truth - always a big if when trying to debug events - I appear to be getting the MouseClickState created with a firstClickTime ~ 6655941 and then a subsequent event with a timeStamp of 3629982911523. Which is really *quite* a long time after if you believe it to be in the same time units as the first click time. Interestingly the following event that has the mouse up which leads to the spurious doubleClickTimeout has a timestamp ~ 6656027 or rather similar to the firstclicktime.
So I guess somewhere an event is being made with the microsecond time value, or possibly, junk.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
The severity of the itch is proportional to the reach.

> On 11-01-2016, at 4:41 PM, tim Rowledge <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
Fractured Idiom:- APRES MOE LE DELUGE - Larry and Curly get wet

So it has been broken some time ago? There is just no double-click in the default tools? :)

Best,
Marcel

> On 12-01-2016, at 4:22 AM, marcel.taeumel <[hidden email]> wrote:
>
> So it has been broken some time ago? There is just no double-click in the
> default tools? :)

It’s broken by Eliot’s recent changes to the millisecond time stuff. The vm still passes events in with a 32 bit timestamp based on ioMSecs() but the various ‘faked’ events we have to use such as MouseEvent>asMouseMove use Time>millisecondClockValue. Which *used* to be based on ioMSecs() as well but is no longer. Thus any d-clicking will generally have problems because the core MouseClickState code must inevitably get confused by the resultant attempts to compare ioMSecs() values in the few-million range with primitive 241 values in the range umpty-gazillion.

The obvious nice way to deal with this is to upgrade the vm but that would screw all previous images and so on. Bad idea. Another option would be to add a method to one or other event related class to keep using the old prim for a millisecond value and update the user methods - ok for future images, mildly annoying but livable (maybe) for older ones. Or maybe it would be manageable to keep the millisecondsClockValue (either in the prim code or by in-image offset) working off the same base as the ioMSecs() code.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: FSRA: Forms Skip and Run-Away

Here -  https://copy.com/wR261WxDYQPLpJya is a proposed fix for the issue. Since the VM passes in a timestamp with events that is derived from ioMSecs() and we have a primitive that also provides a value based on that I simply re-engaged that prim (135) as Time eventMillisecondClock and replaced all the relevant seeming usages of Time millisecondClockValue. So far it appears to function well but there’s always a chance of having missed somewhere, or even being a bit over-enthusiastic. In particular I suspect more cleverness might be needed for the remote event stuff.

Eliot is rather pre-occupied with 64 bit stuff right now so if anyone else could try loading this and checking it out that would be helpful. It’s fairly urgent to get it working.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Multitasking:  Screwing up several things at once...