I have Ye Ancient Code using drag & drop morphs; I need to update it. I'm making a little progress but could do with some pointers on how it changed and what to look out for.
For example, so far as I can tell the old way involved #rejectDropEvent: (why do I keep typing #rejectFropEvent:? ) being used once the drop had been rejected and it was responsible for dealing with sending things back, Now it seems to be the place where the decision is made and there is a default implementation in Morph. I deleted the several versions I had in the Olde Code and so far it *appears* to work - but I hate not knowing what should work & why for things that I'm having to repeatedly sort out. Again, so far as I can tell, adding #wantsToBeDropped: seems to be the place to do the deciding.
There are a bunch of #justDroppedInto:event: methods, some in the current image and some from Ye Olde Code and I'm pretty sure some changes must be needed to update things. The swiki page on d&d is from 2001 (by our late friend DNS) and discusses the very old way. It might be nice to be able to update for the current way.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: APX: Apply Power and eXplode
Hi, Tim!
1. Once a morph receives an event, it can reject it due to some general conditions. This is not specific to but includes drop events. The default implementation of #rejectsEvent: considers visibility and locked state of the receiving morph.
2. The default event dispatcher tries to dispatch the event on the morph or any of its submorphs if necessary: Leaves first! It means that the current morph will get the last chance to process the (drop) event. There are some mechanisms that override this behavior, e.g. #mouseDownPriority. Drop events can be rejected for the whole sub-scenegraph with #rejectDropEvent:. However, you should override #repelsMorph:event: for this purpose.
3. Then, a morph gets the chance to actually handle the drop event. (Morph>>#handleEvent: resp. DropEvent>>#sentTo: and Morph>>#handleDropMorph:)
4. Now the methods you should actually implement (besides maybe #repelsMorph:event:) are:
#wantsDroppedMorph:event: #wantsToBeDroppedInto: #acceptDroppingMorph:event: #justDroppedInto:event:
These are more or less self-explaining. Configuring #dropEnabled does not control the whole sub-scenegraph but only one specific morph in the hierarchy.
Maybe, this helps. :)
Best, Marcel
P.S.: Here is a picture with code: http://forum.world.st/file/n4701110/morphic-drop-events.png
-- View this message in context: http://forum.world.st/Drag-drop-in-Morphic-updating-old-code-tp4700849p47011... Sent from the Squeak - Dev mailing list archive at Nabble.com.
Marcel, thank you so much for that. The picture adds a surprisingly useful amount of information.
I had got as far as working out the middle bit - dispatchCropEvent: /wantsDroppedMorph/wantsToBeDroppedInto - but hadn't at all noticed the rejectDropEvent/acceptDroppingMorph stuff. And I just really realised that dispatchDrop… actually runs through all the morphs in aMorph to check *everything* with them, in a way that at least seems to recurse all the way down. That could make for a very long process if dragging, say, a tree of script tiles. I think that if dropping a tree of similar morphs like that it should be ok to usurp rejectDropEvent, pass directly on to acceptDroppingMorph:event: and then just DroppedInto:event: Or, maybe, the smart thing is to use TransferMorph, which looks like it might just handle short-circuiting all that for you.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Oxymorons: Resident alien
squeak-dev@lists.squeakfoundation.org
-
Marcel Taeumel -
tim Rowledge