I answered a little fast. This should work:
acceptDroppingMorph: morphToDrop event: evt
    (morphToDrop isKindOf: TextMorph) ifFalse: [
        ^Project current world acceptDroppingMorph: morphToDrop event: evt].
     ^super acceptDroppingMorph: morphToDrop event: evt

On Mon, Jun 15, 2020 at 3:57 PM karl ramberg <karlramberg at gmail.com> wrote:

> Try this
> *PasteUpMorphXX>>acceptDroppingMorph: morphToDrop event: evt*
>     (morphToDrop isKindOf: TextMorphXX) ifFalse: [
>         ^morphToDrop rejectDropMorphEvent: evt].
>     super acceptDroppingMorph: aPiece event: evt.
>
> Best,
> Karl
>
>
> On Mon, Jun 15, 2020 at 3:47 PM Trygve Reenskaug <trygver at ifi.uio.no>
> wrote:
>
>> Not quite. Joe now throws the the strange Morph back to where it came
>> from instead of ignoring it.
>> I need Joe to accept all TexMorphXX but ignore the rest.
>>
>> *PasteUpMorphXX>>acceptDroppingMorph: morphToDrop event: evt*
>>     (morphToDrop isKindOf: TextMorphXX) ifFalse: [
>>         ^morphToDrop rejectDropMorphEvent: evt].
>>
>>
>>
>>
>> On 2020.06.15 15:13, karl ramberg wrote:
>>
>> Hi,
>> When you open a morph for dropping it will accept all dropped morphs:
>> joe dropEnabled: true.
>>
>> To filter what is accepted you must override acceptDroppingMorph: aMorph
>> event: evt
>> Look at implementors for that method.
>>
>> Best,
>> Karl
>>
>>
>>
>> On Mon, Jun 15, 2020 at 2:44 PM Trygve Reenskaug <trygver at ifi.uio.no>
>> wrote:
>>
>>> Hi Squeakers,
>>> My SRE context browser is a tool for drawing a snapshot of a selected
>>> structure of interlinked objects where each object is shown as a
>>> rectangular symbol. This diagram shows an object with its class and
>>> superclass objects:
>>>
>>>
>>> SRE has worked for years, last in 'Squeak3.10.2'. In 'Squeak5.3', the
>>> same program went into an infinite loop. It transpired that *myClass>>processEvent:
>>> anEvent using: defaultDispatcher* had become a new thing called an
>>> event filter and needed to return an Event or a Symbol. That problem fixed;
>>> the program still misbehaves. The problem seems to be with event handling.
>>> I have never been into that corner of Smalltalk but have read some Squeak
>>> documentation. I have not found any concrete code.  I realize that I will
>>> never understand Squeak's event handling by reading code, code comments,
>>> and even the documentation I have found. There has apparently been a
>>> significant increase in complexity lately. An example: In 3,10,2, class *MorphicEventDispatcher
>>> *has 4 methods. In 5,3, it has 16.
>>>
>>> Here's the beginning of my challenges with 5.3: I find two anomalies in
>>> a diagram with just one symbol:
>>>
>>>    1.     When I move some other window to a position within the
>>>    diagram, the diagram grabs it and makes it a submorph of itself.  In
>>>    3.10.2, the diagram ignores it.
>>>    2.     The cursor becomes a text cursor when I move the mouse across
>>>    a symbol.
>>>
>>> I have no explanation for either anomaly. My SRE code is a kludge and is
>>> almost unreadable. It is hard to formulate a question without the whole
>>> code as a background, and I have tried to reproduce them in a simple
>>> example. I managed to reproduce the first, but not the second anomaly. In a
>>> workspace, copy, select,  and do it. The XXX-symbol becomes attached to the
>>> cursor, and I place it in the blue background.
>>>
>>> joe := PasteUpMorph new color: Color lightBlue.
>>> joe bounds: (500 at 400 corner: 800 at 600).
>>> joe dropEnabled: true.
>>> joe openInWorld.
>>> circle := CircleMorph new.
>>> joe addMorphCentered: circle.
>>> tex := TextMorphXX new
>>>         contents: 'XXX';
>>>         borderWidth: 1;
>>>         color: Color red;
>>>         extent: 100 at 100.
>>> tex openInHand.
>>>
>>> There is only one  method in class TextMorphXX (sco TextMorph):
>>>
>>> processEvent: anEvent using: defaultDispatcher
>>>     ^#rejected
>>>
>>>
>>>
>>> I move some background window,  actually a collapsed Monticello thing,
>>> to Joe's position, Joe grabs it and makes it into a submorph. Any hints
>>> about how to proceed will be greatly appreciated.
>>> --Trygve
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>>
>>> *The essence of object orientation is that objects collaborate  to
>>> achieve a goal. *
>>> Trygve Reenskaug      mailto: trygver at ifi.uio.no <%20trygver at ifi.uio.no>
>>> Morgedalsvn. 5A       http://folk.uio.no/trygver/
>>> N-0378 Oslo             http://fullOO.info
>>> Norway                     Tel: (+47) 468 58 625
>>>
>>>
>>
>> --
>>
>> *The essence of object orientation is that objects collaborate  to
>> achieve a goal. *
>> Trygve Reenskaug      mailto: trygver at ifi.uio.no <%20trygver at ifi.uio.no>
>> Morgedalsvn. 5A       http://folk.uio.no/trygver/
>> N-0378 Oslo             http://fullOO.info
>> Norway                     Tel: (+47) 468 58 625
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200615/fd9dd0b6/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: clfapgjkmegmpnfm.gif
Type: image/gif
Size: 14037 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200615/fd9dd0b6/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ojfapckoaibeechh.png
Type: image/png
Size: 42394 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200615/fd9dd0b6/attachment-0001.png>