"Andreas Raab" <andreas.raab at gmx.de> wrote on 20.02.2004 19:04:20:
>
>> I see the same ( 1-4 ) on Windows, but I also see it on 3.6. 
>> Sometimes something strange happens, and from there on, a morphic 
>> project ( only that single project ) seems to delay event related 
>> things endlessly, e. g. buttons which have an action for a 1 sec 
>> hold registered, are not reacting to std clicks anymore, they 
>> always think I pressed them 1 sec :)
>
>Looks like a weird combination of things. First of all I believe for 
>some reason your system has "dropped" Sensor's event queue (this is 
>possible - it happens for example under certain error conditions - 
>check out "Sensor eventQueue" to see if it's nil). When that happens, 
>Sensor's ioProcess will start to "throw away" events it receives from 
>the VM (since it doesn't have an event queue any longer it's the only 
>reasonable thing to do :-). Lastly, if you look at, e.g., 
>SimpleButtonMorph>>mouseDown: you will see a delay which is triggered 
>if the button action does not happen on #mouseDown. 
>
>So what probably happens is somewhere along the lines of:
>* you mouse down on the close button
>* the delay in SimpleButtonMorph is activated
>    * you release the mouse
>    * the event is thrown away by ioProcess
>    * you move the mouse to a new position
>    * the event(s) get thrown away as well
>* ages later, the delay ends
>* hand morph asks for the new event from Sensor
>* Sensor synthesizes a mouse up but because it doesn't have the 
>(buffered) position of the mouse up event it uses the current one
>* the mouse up happens in the wrong place.
>
>Interesting that it works at all. How to fix it? Either make sure 
>Sensor *does* have an event queue (Sensor eventQueue: SharedQueue 
>new) or just try the recent change set I sent out for dealing with 
>the ioProcess. 
>
>Cheers,
>  - Andreas

Sensor eventQueue is not nil, and your NoEventSensorProcess-ar.3.cs 
seems to make no difference. Trying to remember after what cases the 
'event responsiveness' slows down, I came up with this: 

- Make a drag and drop in a browser of a method into a class, where 
the method can't be compiled ( inst var ) so that the debugger comes 
up ( and the dragNdrop operation is perhaps not completed correctly ).
 
- Close the debugger. 

>From now on in this project strange things happen. The more windows 
are open, the more often. But the behavior is not constant. I seem to 
remember, that leaving the project and coming back, does not change 
things. But I couldn't reproduce this right now. 

I tried a virgin 3.6-5424 and a nearly virgin 3.7-5707 image, and I 
think the effect of dragging the mouse away after clicking a close 
button ( and not closing the window or menu ) increases after this 
dragNdrop-operation. 

These effects I notice:

- after clicking the close button, it becomes _very_ easy to drag the 
mouse away, so that no close happens. The effect is a bit weaker for 
menu entries 
- these 1 sec hold-action buttons sometimes think after a click they 
have gotten pressed 1 sec, even if the mouse isn't moved.
- it seems to become worse with more windows open

All that on a slow machine: PC 266Mhz ( Win2K ).

Regards
Martin