Bert Freudenberg wrote:
> No, it should be changed to not use Sensor directly.

Indeed. This is also subtly broken in the presence of multiple hands. 
What it should do is determine the hand that is dragging it, remember 
that hand and then use "hand shiftPressed". Unfortunately, this requires 
the users of TransferMorph to be fixed so that they pass a valid hand in 
the drag process since TransferMorph itself can't easily figure out 
which hand is responsible.

Cheers,
   - Andreas

> - Bert -
> 
> On 22.12.2008, at 00:12, karl ramberg wrote:
> 
>> So maybe the TransferMorph>>step should have a 'self  delete' if owner
>> is not a hand morph? Or is there cases where transferMorphs live by
>> them self ?
>>
>> Karl
>>
>> On 12/21/08, Bert Freudenberg <bert at freudenbergs.de> wrote:
>>>
>>> On 21.12.2008, at 21:06, Julian Fitzell wrote:
>>>
>>>> On Sun, Dec 21, 2008 at 8:38 PM, Andreas Raab <andreas.raab at gmx.de>
>>>> wrote:
>>>>> Julian Fitzell wrote:
>>>>>>
>>>>>> Did anybody ever figure out what the heck is causing this? It's
>>>>>> driving me nuts!!
>>>>>
>>>>> It's users of Sensor>>mouseButtons, Sensor>>shiftPressed etc. The
>>>>> main
>>>>> suspect in this regard is TransferMorph which does this:
>>>>>
>>>>> TransferMorph>>step
>>>>>      self shouldCopy: Sensor shiftPressed.
>>>>>      self updateCopyIcon
>>>>>
>>>>> A lingering TransforMorph (which can happen after DnD errors) will
>>>>> happily
>>>>> eat all your events.
>>>>
>>>> Thank you, thank you, thank you. This fixed it:
>>>>
>>>> TransferMorph allInstances do: [:ea | ea delete]
>>>>
>>>> (there was a lingering one - it had an omnibrowser method node as a
>>>> passenger)
>>>>
>>>> Not sure why this is happening so much to me right now but at least I
>>>> have a fix.
>>>
>>>
>>> Oh great! We have encountered this from time to time but never got
>>> down to the cause. Thanks Andreas!
>>>
>>> - Bert -
>>>
>>>
>>>
>>>
>>
> 
> 
> 
> 
>