Problems with a Morph that accepts File Dropping in Pharo 1.3+

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

Problems with a Morph that accepts File Dropping in Pharo 1.3+

Helene Bilbo
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.
Reply | Threaded
Open this post in threaded view
|

Re: Problems with a Morph that accepts File Dropping in Pharo 1.3+

Stéphane Ducasse
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-Pharo-1-3-tp4648385.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>


Reply | Threaded
Open this post in threaded view
|

Re: Problems with a Morph that accepts File Dropping in Pharo 1.3+

Helene Bilbo
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
Reply | Threaded
Open this post in threaded view
|

Re: Problems with a Morph that accepts File Dropping in Pharo 1.3+

Stéphane Ducasse
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-Pharo-1-3-tp4648385p4648486.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>


Reply | Threaded
Open this post in threaded view
|

Re: Problems with a Morph that accepts File Dropping in Pharo 1.3+

Helene Bilbo
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.
Reply | Threaded
Open this post in threaded view
|

Re: Problems with a Morph that accepts File Dropping in Pharo 1.3+

Stéphane Ducasse


> 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-Pharo-1-3-tp4648385p4648540.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>


Reply | Threaded
Open this post in threaded view
|

Re: Problems with a Morph that accepts File Dropping in Pharo 1.3+

Helene Bilbo
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..
Reply | Threaded
Open this post in threaded view
|

Re: Problems with a Morph that accepts File Dropping in Pharo 1.3+

Stéphane Ducasse
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-Pharo-1-3-tp4648385p4648551.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>


Reply | Threaded
Open this post in threaded view
|

Re: Problems with a Morph that accepts File Dropping in Pharo 1.3+

Stéphane Ducasse
In reply to this post by Helene Bilbo

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-Pharo-1-3-tp4648385p4648551.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>


Reply | Threaded
Open this post in threaded view
|

Re: Problems with a Morph that accepts File Dropping in Pharo 1.3+

Stéphane Ducasse
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
Reply | Threaded
Open this post in threaded view
|

Re: Problems with a Morph that accepts File Dropping in Pharo 1.3+

Stéphane Ducasse
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


Reply | Threaded
Open this post in threaded view
|

Re: Problems with a Morph that accepts File Dropping in Pharo 1.3+

Helene Bilbo
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
Reply | Threaded
Open this post in threaded view
|

Re: Problems with a Morph that accepts File Dropping in Pharo 1.3+

Stéphane Ducasse
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-Pharo-1-3-tp4648385p4648634.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>


Reply | Threaded
Open this post in threaded view
|

Re: Problems with a Morph that accepts File Dropping in Pharo 1.3+

Stéphane Ducasse
In reply to this post by Helene Bilbo
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
Reply | Threaded
Open this post in threaded view
|

Re: Problems with a Morph that accepts File Dropping in Pharo 1.3+

Sven Van Caekenberghe-2

On 24 Sep 2012, at 19:55, Stéphane Ducasse <[hidden email]> 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




Reply | Threaded
Open this post in threaded view
|

Re: Problems with a Morph that accepts File Dropping in Pharo 1.3+

Helene Bilbo
In reply to this post by Stéphane Ducasse
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..
Reply | Threaded
Open this post in threaded view
|

Re: Problems with a Morph that accepts File Dropping in Pharo 1.3+

Igor Stasenko
looks like Esteban's latest commit reverted some stuff. or else i dont
know what happens

On 24 September 2012 21:07, Helene Bilbo
<[hidden email]> 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-Pharo-1-3-tp4648385p4648833.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>



--
Best regards,
Igor Stasenko.

Reply | Threaded
Open this post in threaded view
|

Re: Problems with a Morph that accepts File Dropping in Pharo 1.3+

EstebanLM
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 <[hidden email]> 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
> <[hidden email]> 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-Pharo-1-3-tp4648385p4648833.html
>> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>>
>
>
>
> --
> Best regards,
> Igor Stasenko.
>


Reply | Threaded
Open this post in threaded view
|

Re: Problems with a Morph that accepts File Dropping in Pharo 1.3+

Igor Stasenko
On 24 September 2012 22:03, Esteban Lorenzano <[hidden email]> 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 <[hidden email]> 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
>> <[hidden email]> 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-Pharo-1-3-tp4648385p4648833.html
>>> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko.
>>
>
>



--
Best regards,
Igor Stasenko.

Reply | Threaded
Open this post in threaded view
|

Re: Problems with a Morph that accepts File Dropping in Pharo 1.3+

LogiqueWerks
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

12