Problems with a Morph that accepts File Dropping in Pharo 1.3+
Hi, i still have problems with a Morph that should accept files from the OS dragged and dropped onto it. I found out it works in Pharo 1.2 and in Squeak 4.3 but not in Pharo 1.3 and 1.4. Try this class: Morph subclass: #DropZone instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'DragAndDrop'! !DropZone methodsFor: 'as yet unclassified' stamp: 'HeleneBilbo 9/21/2012 20:53'! dropFiles: evt self color: Color blue.! ! !DropZone methodsFor: 'as yet unclassified' stamp: 'HeleneBilbo 9/21/2012 20:41'! initialize super initialize. color := Color red. bounds := 0 @ 0 extent: 200 @ 200! ! !DropZone methodsFor: 'as yet unclassified' stamp: 'HeleneBilbo 9/21/2012 20:53'! wantsDropFiles: anEvent ^ true! ! In Pharo 1.3 and 1.4 the DropZone Morph does only in some rare cases catch the dropped file, in most cases it's the PastUpMorph behind, that get's to handle the dropped file. In Pharo 1.2 and in Squeak (4.3) it works as it should, i.e. the DropZone always get's to handle the file dropped onto it. Perhaps someone has an idea what changed between 1.2 and 1.3 that could cause this behavior? Best regards, Helene. -- View this message in context: http://forum.world.st/Problems-with-a-Morph-that-accepts-File-Dropping-in-Ph... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
helene can you send the cs file? On Sep 21, 2012, at 10:26 PM, Helene Bilbo wrote:
Hi, i still have problems with a Morph that should accept files from the OS dragged and dropped onto it. I found out it works in Pharo 1.2 and in Squeak 4.3 but not in Pharo 1.3 and 1.4. Try this class:
Morph subclass: #DropZone instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'DragAndDrop'!
!DropZone methodsFor: 'as yet unclassified' stamp: 'HeleneBilbo 9/21/2012 20:53'! dropFiles: evt self color: Color blue.! !
!DropZone methodsFor: 'as yet unclassified' stamp: 'HeleneBilbo 9/21/2012 20:41'! initialize super initialize. color := Color red. bounds := 0 @ 0 extent: 200 @ 200! !
!DropZone methodsFor: 'as yet unclassified' stamp: 'HeleneBilbo 9/21/2012 20:53'! wantsDropFiles: anEvent ^ true! !
In Pharo 1.3 and 1.4 the DropZone Morph does only in some rare cases catch the dropped file, in most cases it's the PastUpMorph behind, that get's to handle the dropped file. In Pharo 1.2 and in Squeak (4.3) it works as it should, i.e. the DropZone always get's to handle the file dropped onto it.
Perhaps someone has an idea what changed between 1.2 and 1.3 that could cause this behavior?
Best regards, Helene.
-- View this message in context: http://forum.world.st/Problems-with-a-Morph-that-accepts-File-Dropping-in-Ph... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Stéphane Ducasse wrote
helene can you send the cs file?
I send it as attachment. Just open an instance of DropZone in the world and start dropping files onto it. In 1.2 and in Squeak it works well, in 1.3 and 1.4 it sometimes works, when you make the morph really big, but it doesn't work or seldom works with smaller Morphs. I could not find where the problem lies. helene. DragAndDrop.st <http://forum.world.st/file/n4648486/DragAndDrop.st> -- View this message in context: http://forum.world.st/Problems-with-a-Morph-that-accepts-File-Dropping-in-Ph... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
which kind of files are you dropping because dropping a .st file does the same on 2.0 and 1.2 stef On Sep 22, 2012, at 7:01 PM, Helene Bilbo wrote:
Stéphane Ducasse wrote
helene can you send the cs file?
I send it as attachment.
Just open an instance of DropZone in the world and start dropping files onto it.
In 1.2 and in Squeak it works well, in 1.3 and 1.4 it sometimes works, when you make the morph really big, but it doesn't work or seldom works with smaller Morphs. I could not find where the problem lies.
helene. DragAndDrop.st <http://forum.world.st/file/n4648486/DragAndDrop.st>
-- View this message in context: http://forum.world.st/Problems-with-a-Morph-that-accepts-File-Dropping-in-Ph... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Stéphane Ducasse wrote
which kind of files are you dropping because dropping a .st file does the same on 2.0 and 1.2
Yes, that's the problem. It's PasteUpMorph that handles all the dropped files. I want to make a custom Morph, DropZone, that handles dropped files. Of course i could alter PasteUpMorph, but there is a functionality that worked in 1.2 and works in Squeak, that ceased to work in 1.3+, that allowed to make morphs that handle dropped files. Background: I made an application for the psychology department of a university that parses Tobii eyetracker files (with PetitParser, which works AMAZINGLY WELL!) and does all sorts of calculations with them. I want to provide a nice interface, that allows users to drop the eyetracker files on a Pharo window to start the file processing. -- View this message in context: http://forum.world.st/Problems-with-a-Morph-that-accepts-File-Dropping-in-Ph... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Stéphane Ducasse wrote
which kind of files are you dropping because dropping a .st file does the same on 2.0 and 1.2
Yes, that's the problem. It's PasteUpMorph that handles all the dropped files. I want to make a custom Morph, DropZone, that handles dropped files. Of course i could alter PasteUpMorph, but there is a functionality that worked in 1.2 and works in Squeak, that ceased to work in 1.3+, that allowed to make morphs that handle dropped files.
Do you have a scenario that works in 1.2 because I got exactly the same behavior with 1.2 and 2.0? When I drop a txt file I get a workspace in both version. When do you get your halt open. in 1.2 I put an halt into Morph>>handleDropFiles: anEvent "Handle a drop from the OS." self halt. anEvent wasHandled ifTrue:[^self]. "not interested" (self wantsDropFiles: anEvent) ifFalse:[^self]. anEvent wasHandled: true. self dropFiles: anEvent. I tried the same on 2.0 and this is in both cases the PasteUpMorph that get it. So. ok in 1.1-11411 I got your halt. :) MorphicEventDispatcher>>dispatchDefault: anEvent with: aMorph "Dispatch the given event. The event will be passed to the front-most visible submorph that contains the position wrt. to the event." | localEvt index child morphs inside | "See if we're fully outside aMorphs bounds" (aMorph fullBounds containsPoint: anEvent position) ifFalse:[^#rejected]. "outside" "Traverse children" index := 1. morphs := aMorph submorphs. inside := false. [index <= morphs size] whileTrue:[ child := morphs at: index. localEvt := anEvent transformedBy: (child transformedFrom: aMorph). (child processEvent: localEvt using: self) == #rejected ifFalse:[ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ "Not rejected. The event was in some submorph of the receiver" inside := true. localEvt wasHandled ifTrue:[anEvent copyHandlerState: localEvt]. index := morphs size. "break" ]. index := index + 1. ]. "Check for being inside the receiver" inside ifFalse:[inside := aMorph containsPoint: anEvent position event: anEvent]. inside ifTrue:[^aMorph handleEvent: anEvent]. ^#rejected
Background: I made an application for the psychology department of a university that parses Tobii eyetracker files (with PetitParser, which works AMAZINGLY WELL!) and does all sorts of calculations with them. I want to provide a nice interface, that allows users to drop the eyetracker files on a Pharo window to start the file processing.
-- View this message in context: http://forum.world.st/Problems-with-a-Morph-that-accepts-File-Dropping-in-Ph... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Stéphane Ducasse wrote
I tried the same on 2.0 and this is in both cases the PasteUpMorph that get it. So.
ok in 1.1-11411 I got your halt. :)
So, you found my problem :) Any idea, what i can do about it? It is a pity (and a bug - as when you make the custom DropZone morph bigger, some parts of it handle the dropped file, while some other parts of it, pass it on to the PasteUpMorph) that it does no longer work this way, and i could not find any reason for it.. -- View this message in context: http://forum.world.st/Problems-with-a-Morph-that-accepts-File-Dropping-in-Ph... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
I will try to have a look. Now putting a halt in such method can block everything :) Stef On Sep 23, 2012, at 4:35 PM, Helene Bilbo wrote:
Stéphane Ducasse wrote
I tried the same on 2.0 and this is in both cases the PasteUpMorph that get it. So.
ok in 1.1-11411 I got your halt. :)
So, you found my problem :)
Any idea, what i can do about it?
It is a pity (and a bug - as when you make the custom DropZone morph bigger, some parts of it handle the dropped file, while some other parts of it, pass it on to the PasteUpMorph) that it does no longer work this way, and i could not find any reason for it..
-- View this message in context: http://forum.world.st/Problems-with-a-Morph-that-accepts-File-Dropping-in-Ph... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
On Sep 23, 2012, at 4:35 PM, Helene Bilbo wrote:
Stéphane Ducasse wrote
I tried the same on 2.0 and this is in both cases the PasteUpMorph that get it. So.
ok in 1.1-11411 I got your halt. :)
So, you found my problem :)
not really so far the code is the same. dispatchDefault: anEvent with: aMorph Now this method is used continuously. I put an halt inside to get a debugger when the drop event is managed dispatchDefault: anEvent with: aMorph "Dispatch the given event. The event will be passed to the front-most visible submorph that contains the position wrt. to the event." | localEvt index child morphs inside | "See if we're fully outside aMorphs bounds" (aMorph fullBounds containsPoint: anEvent position) ifFalse:[^#rejected]. "outside" "Traverse children" index := 1. morphs := aMorph submorphs. inside := false. [index <= morphs size] whileTrue:[ child := morphs at: index. localEvt := anEvent transformedBy: (child transformedFrom: aMorph). (child processEvent: localEvt using: self) == #rejected ifFalse:[ "Not rejected. The event was in some submorph of the receiver" inside := true. localEvt wasHandled ifTrue:[anEvent copyHandlerState: localEvt]. index := morphs size. "break" ]. index := index + 1. ]. "Check for being inside the receiver" anEvent class = DropFilesEvent ifTrue: [self halt.]. inside ifFalse:[inside := aMorph containsPoint: anEvent position event: anEvent]. inside ifTrue:[^aMorph handleEvent: anEvent]. ^#rejected Now in Pharo 2.0 dispatchEvent: anEvent with: aMorph "Dispatch the given event for a morph that has chosen the receiver to dispatch its events. The method implements a shortcut for repeated dispatches of events using the same dispatcher." anEvent type == lastType ifTrue:[^self perform: lastDispatch with: anEvent with: aMorph]. "Otherwise classify" lastType := anEvent type. anEvent isMouse ifTrue:[ anEvent isMouseDown ifTrue:[ lastDispatch := #dispatchMouseDown:with:. ^self dispatchMouseDown: anEvent with: aMorph]]. anEvent type == #dropEvent ifTrue:[ lastDispatch := #dispatchDropEvent:with:. ^self dispatchDropEvent: anEvent with: aMorph]. anEvent isWindowEvent ifTrue:[ lastDispatch := #dispatchWindowEvent:with:. ^self dispatchWindowEvent: anEvent with: aMorph]. lastDispatch := #dispatchDefault:with:. ^self dispatchDefault: anEvent with: aMorph the last line is executed while in 1.1 dispatchEvent: anEvent with: aMorph "Dispatch the given event for a morph that has chosen the receiver to dispatch its events. The method implements a shortcut for repeated dispatches of events using the same dispatcher." anEvent type == lastType ifTrue:[^self perform: lastDispatch with: anEvent with: aMorph]. it stopped in this branch. "Otherwise classify" lastType := anEvent type. anEvent isMouse ifTrue:[ anEvent isMouseDown ifTrue:[ lastDispatch := #dispatchMouseDown:with:. ^self dispatchMouseDown: anEvent with: aMorph]]. anEvent type == #dropEvent ifTrue:[ lastDispatch := #dispatchDropEvent:with:. ^self dispatchDropEvent: anEvent with: aMorph]. anEvent isWindowEvent ifTrue:[ lastDispatch := #dispatchWindowEvent:with:. ^self dispatchWindowEvent: anEvent with: aMorph]. lastDispatch := #dispatchDefault:with:. ^self dispatchDefault: anEvent with: aMorph
Any idea, what i can do about it?
It is a pity (and a bug - as when you make the custom DropZone morph bigger, some parts of it handle the dropped file, while some other parts of it, pass it on to the PasteUpMorph) that it does no longer work this way, and i could not find any reason for it..
-- View this message in context: http://forum.world.st/Problems-with-a-Morph-that-accepts-File-Dropping-in-Ph... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
but this is the same :) Slowly debugging step by step the process it seems that the (aMorph fullBounds containsPoint: anEvent position) ifFalse:[^#rejected]. "outside" pass in the false path in 20 and true path in 1.1 May be localEvt := anEvent transformedBy: (child transformedFrom: aMorph). the transformation changed the position. Stef
What is really strange is that the event location is always too large. I put the dropZone on 0@0 - 200@200 and I drop a file on it and the event location is 15@800â¦. I traced that up to HandMorphâ¦processEvents and this is event in the evtBuf of the vm. Stef dispatchDefault: anEvent with: aMorph "Dispatch the given event. The event will be passed to the front-most visible submorph that contains the position wrt. to the event." | localEvt index child morphs inside | "See if we're fully outside aMorphs bounds" (anEvent class = DropFilesEvent ) and: [(aMorph class = DropZone) ifTrue: [self halt]]. (aMorph fullBounds containsPoint: anEvent position) ifFalse:[^#rejected]. "outside" "Traverse children" index := 1. morphs := aMorph submorphs. inside := false. [index <= morphs size] whileTrue:[ child := morphs at: index. localEvt := anEvent transformedBy: (child transformedFrom: aMorph). (child processEvent: localEvt using: self) == #rejected ifFalse:[ "Not rejected. The event was in some submorph of the receiver" inside := true. localEvt wasHandled ifTrue:[anEvent copyHandlerState: localEvt]. index := morphs size. "break" ]. index := index + 1. ]. "Check for being inside the receiver" inside ifFalse:[inside := aMorph containsPoint: anEvent position event: anEvent]. inside ifTrue:[^aMorph handleEvent: anEvent]. ^#rejected
Thanks for investigating my issue - and for documenting how you did so! That's interesting to read. I would not have found the right way to modify and halt the dispatchDefault: anEvent with: aMorph method myself.. Something like this would be a nice screencast for beginners on PharoCasts. helene. Stéphane Ducasse wrote
What is really strange is that the event location is always too large. I put the dropZone on 0@0 - 200@200 and I drop a file on it and the event location is 15@800â¦. I traced that up to HandMorphâ¦processEvents and this is event in the evtBuf of the vm.
Stef
dispatchDefault: anEvent with: aMorph "Dispatch the given event. The event will be passed to the front-most visible submorph that contains the position wrt. to the event." | localEvt index child morphs inside | "See if we're fully outside aMorphs bounds" (anEvent class = DropFilesEvent ) and: [(aMorph class = DropZone) ifTrue: [self halt]]. (aMorph fullBounds containsPoint: anEvent position) ifFalse:[^#rejected]. "outside" "Traverse children" index := 1. morphs := aMorph submorphs. inside := false. [index <= morphs size] whileTrue:[ child := morphs at: index. localEvt := anEvent transformedBy: (child transformedFrom: aMorph). (child processEvent: localEvt using: self) == #rejected ifFalse:[ "Not rejected. The event was in some submorph of the receiver" inside := true. localEvt wasHandled ifTrue:[anEvent copyHandlerState: localEvt]. index := morphs size. "break" ]. index := index + 1. ].
"Check for being inside the receiver" inside ifFalse:[inside := aMorph containsPoint: anEvent position event: anEvent]. inside ifTrue:[^aMorph handleEvent: anEvent]. ^#rejected
-- View this message in context: http://forum.world.st/Problems-with-a-Morph-that-accepts-File-Dropping-in-Ph... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Helene two key things: - look for senders - put a halt there and check at worse you crash the system :) Stef On Sep 24, 2012, at 9:28 AM, Helene Bilbo wrote:
Thanks for investigating my issue - and for documenting how you did so! That's interesting to read. I would not have found the right way to modify and halt the dispatchDefault: anEvent with: aMorph method myself.. Something like this would be a nice screencast for beginners on PharoCasts. helene.
Stéphane Ducasse wrote
What is really strange is that the event location is always too large. I put the dropZone on 0@0 - 200@200 and I drop a file on it and the event location is 15@800â¦. I traced that up to HandMorphâ¦processEvents and this is event in the evtBuf of the vm.
Stef
dispatchDefault: anEvent with: aMorph "Dispatch the given event. The event will be passed to the front-most visible submorph that contains the position wrt. to the event." | localEvt index child morphs inside | "See if we're fully outside aMorphs bounds" (anEvent class = DropFilesEvent ) and: [(aMorph class = DropZone) ifTrue: [self halt]]. (aMorph fullBounds containsPoint: anEvent position) ifFalse:[^#rejected]. "outside" "Traverse children" index := 1. morphs := aMorph submorphs. inside := false. [index <= morphs size] whileTrue:[ child := morphs at: index. localEvt := anEvent transformedBy: (child transformedFrom: aMorph). (child processEvent: localEvt using: self) == #rejected ifFalse:[ "Not rejected. The event was in some submorph of the receiver" inside := true. localEvt wasHandled ifTrue:[anEvent copyHandlerState: localEvt]. index := morphs size. "break" ]. index := index + 1. ].
"Check for being inside the receiver" inside ifFalse:[inside := aMorph containsPoint: anEvent position event: anEvent]. inside ifTrue:[^aMorph handleEvent: anEvent]. ^#rejected
-- View this message in context: http://forum.world.st/Problems-with-a-Morph-that-accepts-File-Dropping-in-Ph... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Hi helene As I was thinking after investigating the problems, there was a bug in the VM. Esteban fixed it. The point is that the mac event location was not converted to the right coordinate system. Now this is fixed. Grab the most recent VM from the jenkins server and let us know. Thanks for spotting the bug. Stef
On 24 Sep 2012, at 19:55, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Thanks for spotting the bug.
Yes indeed: people reporting bugs like that (with code, being knowledgeable and persistent) are really very helpful. Thanks. -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
Stéphane Ducasse wrote
As I was thinking after investigating the problems, there was a bug in the VM. Esteban fixed it. The point is that the mac event location was not converted to the right coordinate system. Now this is fixed. Grab the most recent VM from the jenkins server and let us know. Thanks for spotting the bug.
Thank you. I am waiting for the VM, at the moment there seems to be a new problem as the build failed: https://ci.lille.inria.fr/pharo/view/Cog/job/Cog-VM/ or i am just too impatient.. -- View this message in context: http://forum.world.st/Problems-with-a-Morph-that-accepts-File-Dropping-in-Ph... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
looks like Esteban's latest commit reverted some stuff. or else i dont know what happens On 24 September 2012 21:07, Helene Bilbo <thereluctantprogrammer@fastmail.fm> wrote:
Stéphane Ducasse wrote
As I was thinking after investigating the problems, there was a bug in the VM. Esteban fixed it. The point is that the mac event location was not converted to the right coordinate system. Now this is fixed. Grab the most recent VM from the jenkins server and let us know. Thanks for spotting the bug.
Thank you. I am waiting for the VM, at the moment there seems to be a new problem as the build failed: https://ci.lille.inria.fr/pharo/view/Cog/job/Cog-VM/ or i am just too impatient..
-- View this message in context: http://forum.world.st/Problems-with-a-Morph-that-accepts-File-Dropping-in-Ph... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
I souldn't... I merge blessed and mine, I think I didn't stepped on anything On Sep 24, 2012, at 9:36 PM, Igor Stasenko <siguctua@gmail.com> wrote:
looks like Esteban's latest commit reverted some stuff. or else i dont know what happens
On 24 September 2012 21:07, Helene Bilbo <thereluctantprogrammer@fastmail.fm> wrote:
Stéphane Ducasse wrote
As I was thinking after investigating the problems, there was a bug in the VM. Esteban fixed it. The point is that the mac event location was not converted to the right coordinate system. Now this is fixed. Grab the most recent VM from the jenkins server and let us know. Thanks for spotting the bug.
Thank you. I am waiting for the VM, at the moment there seems to be a new problem as the build failed: https://ci.lille.inria.fr/pharo/view/Cog/job/Cog-VM/ or i am just too impatient..
-- View this message in context: http://forum.world.st/Problems-with-a-Morph-that-accepts-File-Dropping-in-Ph... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
On 24 September 2012 22:03, Esteban Lorenzano <estebanlm@gmail.com> wrote:
I souldn't... I merge blessed and mine, I think I didn't stepped on anything
but current builds failed because of some out-of-sync in file plugin (again).. it may be you using wrong VMMaker sources then.
On Sep 24, 2012, at 9:36 PM, Igor Stasenko <siguctua@gmail.com> wrote:
looks like Esteban's latest commit reverted some stuff. or else i dont know what happens
On 24 September 2012 21:07, Helene Bilbo <thereluctantprogrammer@fastmail.fm> wrote:
Stéphane Ducasse wrote
As I was thinking after investigating the problems, there was a bug in the VM. Esteban fixed it. The point is that the mac event location was not converted to the right coordinate system. Now this is fixed. Grab the most recent VM from the jenkins server and let us know. Thanks for spotting the bug.
Thank you. I am waiting for the VM, at the moment there seems to be a new problem as the build failed: https://ci.lille.inria.fr/pharo/view/Cog/job/Cog-VM/ or i am just too impatient..
-- View this message in context: http://forum.world.st/Problems-with-a-Morph-that-accepts-File-Dropping-in-Ph... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
Helene - and my thanks to you for your polite persistence - thanks as a Pharo user devoting his time to issues on another dev platform - and me, not by nature diplomatic ;-) In only a few weeks I may be so grateful that file drops work in 1.4+ or a 2.0+ !! Robert, Atlantic Canada
Ok, i just tried everything and it works perfectly. Thank you again. -- View this message in context: http://forum.world.st/Problems-with-a-Morph-that-accepts-File-Dropping-in-Ph... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
excellent! Stef On Sep 25, 2012, at 10:36 PM, Helene Bilbo wrote:
Ok, i just tried everything and it works perfectly. Thank you again.
-- View this message in context: http://forum.world.st/Problems-with-a-Morph-that-accepts-File-Dropping-in-Ph... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
participants (6)
-
Esteban Lorenzano -
Helene Bilbo -
Igor Stasenko -
Robert Shiplett -
Stéphane Ducasse -
Sven Van Caekenberghe