In message <3978FE14.FB8EBEE1 at evolgo.de>
          Stephan Rudlof <sr at evolgo.de> wrote:

> In PluggableListMorphs there are two clicks necessary to deselect/select
> an already selected/deselected item, if the mouse stays at the same
> point. If you move it a little, then you need just one click (as
> expected).
> 
> Seems to be one of the odd (not serious) effects if event stuff is
> introduced.
Fixed it, or should I say, found a workaround.
The bug was noted in several symptonms:-
1. when using meta-F to open a find FillInTheBlank, you had to move the
mouse a little to get the FITB to activate
2. if you deselect an item in a pluggablelistmorph, you had to click
twice to get it to reselelct unles you moved the mouse
3. if you drag select down (or up) out of a view with a large text, the
drag-scroll would stop after a very short while.

All these symptoms are related to an architectural bug in the Morphic
processEvents code. The code is relying on an artifact of the old
mouse-state-polling regime that provided a fake mouse-move event every
time HandMorph>processEvents was called. Naughty code!! It seems
primarily to be related to #mouseOver: not getting called unless this
fake event is provided.
The FITB for example really ought to activate explicitly, since we
deliberately open it, rather than misusing #mouseOver:.

As a workaround, I have made the event code provide a similar fake
mousemove. This is ugly and the proper architectural change should be
made by somebody that really understands the Morphic stuff.

tim
-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Strange OpCodes: ESBD: Erase System and Burn Documentation
-------------- next part --------------
'From Squeak2.8 of 30 June 2000 [latest update: #2348] on 26 July 2000 at 6:58:16 pm'!
"Change Set:		TPR-EventFix1
Date:			26 July 2000
Author:			tim at sumeru.stanford.edu

A fix for a small bug in the event handling workaround related code.
The bug was nnotedin several symptonms:-
1. when using meta-F to open a find FillInTheBlank, you had to move the mouse a little to get the FITB to activate
2. if you deselect an item in a pluggablelistmorph, you had to click twice to get it to reselelct unles you moved the mouse
3. if you drag select down (or up) out of a view with a large text, the drag-scroll would stop after a very short while.

All these symptoms are related to an architectural bug in the Morphic processEvents code. The code is relying on an artifact of the old mouse-state-polling regime that provided a fake mouse-move event every time HandMorph>processEvents was called. Naughty code!! It seems primarily to be related to #mouseOver: not getting called unless this fake event is provided. The FITB for example really ought to activate explicitly, since we deliberately open it, rather than misusing #mouseOver:.

As a workaround, I have made the event code provide a similar fake mousemove. This is ugly and the proper architectural change should be made by somebody that really understands the Morphic stuff."!


!EventSensor methodsFor: 'event api' stamp: 'TPR 7/26/2000 18:48'!
nextMouseEventForHand: aHandMorph
	"return a MorphicEvent for the mouse status. Intended to do the same basic job as the first part of HandMorph processEvents, but obviously not the event transmission. Fake up an event that is as innocuous as possible"

	^MorphicEvent new setHand: aHandMorph;
			setMouseMoveAt: latestEvent cursorPoint
			buttons: latestEvent buttons! !