Some change, probably in Morphic classes, breaks Scratch between #15852 & 16040

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Some change, probably in Morphic classes, breaks Scratch between #15852 & 16040

timrowledge
Whilst attempting a build of Scratch in a fully updated image it became clear that something has pretty seriously changed some part of morph dragging that I relied upon; when I drag a script tile and drop it, it no longer gets dropped into the scripting area but stays in the main world (I think).

In a 15852 update from late April it works ok. In a 16040 update today it doesn’t. That’s a lot of updates to look over… I was intending to start a quick (hah!) binary search for where things went wrong but I can’t find hoe to load updates up to a certain number. I’m sure it used to be there but it might be 15 years since I had reason to do that :-O McmUpdater doesn’t appear to have any code that could do it but where else might I look?

Of course, if anyone can think of a place where my problem might lie, do please let me know.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: BFM: Branch on Full Moon



Reply | Threaded
Open this post in threaded view
|

Re: Some change, probably in Morphic classes, breaks Scratch between #15852 & 16040

marcel.taeumel
tim Rowledge wrote
Whilst attempting a build of Scratch in a fully updated image it became clear that something has pretty seriously changed some part of morph dragging that I relied upon; when I drag a script tile and drop it, it no longer gets dropped into the scripting area but stays in the main world (I think).

In a 15852 update from late April it works ok. In a 16040 update today it doesn’t. That’s a lot of updates to look over… I was intending to start a quick (hah!) binary search for where things went wrong but I can’t find hoe to load updates up to a certain number. I’m sure it used to be there but it might be 15 years since I had reason to do that :-O McmUpdater doesn’t appear to have any code that could do it but where else might I look?

Of course, if anyone can think of a place where my problem might lie, do please let me know.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: BFM: Branch on Full Moon
Hi Tim,

can you provide me an image? I think I know where to look for...

The following things related to drop changed and suspicious overwrites in custom packages/applications might be affected:

HandMorph >> #dropMorph:event: (nobody should have to overwrite this)
Morph >> #processEvent:using: (nobody should have to overwrite this)
Morph >> #handleFocusEvent: (if overwritten, ensure super-call and watch out for #rejected when manually calling #processEvent:; see DockingBarMorph, MenuMorph, and UserDialogBoxBox for example overwrites)

So, I would look for custom implementations in Scratch of the above.

Best,
Marcel
Reply | Threaded
Open this post in threaded view
|

Re: Some change, probably in Morphic classes, breaks Scratch between #15852 & 16040

timrowledge
So far as I can work out *something* is causing the drop to go wrong in a very interesting way. There are always fun problems in debugging events, not least completely crashing the system, so I may be being mislead.

Anyway, it seems that dropping a Scratch script tile onto the script editing pane works as normal BUT something is thinking the drop failed and so goes up to the next level - a the Scratch application main frame - which most definitely rejects the script tile and so it defers back to the pasteupmorph and the tile is ripped out of the script editor and moved to the World. Nasty!

I’m suspicious of the apparent double-send of the events introduced by the filtering, and maybe the whole ‘ignored’ thing.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: MFC: Mangle Following Command