Smalltalk › Cuis Smalltalk

mouseButton2Up:localPosition:

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

9 messages Options

Dan Norton

mouseButton2Up:localPosition:

In the message:

mouseButton2Up: aMouseButtonEvent localPosition: localEventPosition

the parameter 'localEventPosition' is a point in a PasteUpMorph(hash) [world] instead of being relative to the morph where the click was done.

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

Dan Norton

Re: mouseButton2Up:localPosition:

On 19 Apr 2015 at 12:16, Dan Norton wrote:

> In the message:

> mouseButton2Up: aMouseButtonEvent localPosition:

> localEventPosition

> the parameter 'localEventPosition' is a point in a

> PasteUpMorph(hash) [world] instead of being

> relative to the morph where the click was done.

The above method was employed to show a pop-up menu which appeared relative to World (incorrect). If #mouseButton2Activity is used instead of the above method, it will appear in the right place - relative to the morph where the click was done, instead of relative to World.

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

Juan Vuletich-4

Re: mouseButton2Up:localPosition:

On 4/23/2015 8:13 PM, Dan Norton wrote:

> In the message:

> mouseButton2Up: aMouseButtonEvent localPosition:

> localEventPosition

>

> the parameter 'localEventPosition' is a point in a

> PasteUpMorph(hash) [world] instead of being

> relative to the morph where the click was done.

The above method was employed to show a pop-up menu which appeared relative to World (incorrect). If #mouseButton2Activity is used instead of the above method, it will appear in the right place - relative to the morph where the click was done, instead of relative to World.

Hi Dan,

I'm having trouble to understand what you say.

So, I created a new Morph class, and defined

    handlesMouseDown: aMouseButtonEvent
        ^true

and

    mouseButton2Up: aMouseButtonEvent localPosition: localEventPosition
        localEventPosition print

I right click on the morph and the localEventPosition shown in the Transcript is indeed local to the morph.

May I ask you to report bugs in a style like this? I mean, a clear statement on what's happening and what's the problem, and instructions detailed enough to reproduce it.

I can't understand what you are specifically referring to when you say "The above method was employed to show a pop-up menu which appeared relative to World (incorrect). If #mouseButton2Activity is used instead of the above method, it will appear in the right place - relative to the morph where the click was done, instead of relative to World."

Thanks,
Juan Vuletich

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

Dan Norton

Re: mouseButton2Up:localPosition:

On 24 Apr 2015 at 7:58, Juan Vuletich wrote:
[snip]

>
> I can't understand what you are specifically referring to when you
> say "The above method was
> employed to show a pop-up menu which appeared relative to World
> (incorrect). If
> #mouseButton2Activity is used instead of the above method, it will
> appear in the right place -
> relative to the morph where the click was done, instead of relative
> to World."
>

Sorry for the the fog. The attached zip contains two change sets which should show the

problem:

Load both change sets and do: BouncingAtomsMorph new.
Move the window away from the upper left of the display, if necessary.
Right click over the window. Pop-up appears /away/ from where the click is done.

The method #xmouseButton2Activity shows code that works, provided it is renamed
#mouseButton2Activity and #mouseButton2Up:localPosition: is deleted.

I hope this helps :)

- Dan

The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any other MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.

---- File information -----------
File: Button2UpLocation.zip
Date: 24 Apr 2015, 10:50
Size: 5229 bytes.
Type: ZIP-archive

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

Button2UpLocation.zip (6K) Download Attachment

Juan Vuletich-4

Re: mouseButton2Up:localPosition:

Hi Dan,

So, where's the bug? It's in your #mouseButton2Up:localPosition: . You get
a point in local coordinates (you can check this bu just adding
'localEventPosition print'). And you ask for the menu to open there. But
the menu is not a submorph. It will be a submorph of the world. (this is
again easy to check by opening an inspector on the menu, by doing 'self
inspect').

What you want is, instead of just using 'localEventPosition' to use '(self
externalizeToWorld: localEventPosition)'. Your alternative
#xmouseButton2Activity is perfectly fine too.

Cheers,
Juan vuletich

On Fri, April 24, 2015 12:15 pm, Dan Norton wrote:

> On 24 Apr 2015 at 7:58, Juan Vuletich wrote:
> [snip]
>
>>
>> I can't understand what you are specifically referring to when you
>> say "The above method was employed to show a pop-up menu which appeared
>> relative to World (incorrect). If
>> #mouseButton2Activity is used instead of the above method, it will
>> appear in the right place - relative to the morph where the click was
>> done, instead of relative to World."
>>
> Sorry for the the fog. The attached zip contains two change sets which
> should show the problem:
>
>
> Load both change sets and do: BouncingAtomsMorph new.
> Move the window away from the upper left of the display, if necessary.
> Right click over the window. Pop-up appears /away/ from where the click is
> done.
>
> The method #xmouseButton2Activity shows code that works, provided it is
> renamed #mouseButton2Activity and #mouseButton2Up:localPosition: is
> deleted.
>
> I hope this helps :)
>
>
> - Dan
> The following section of this message contains a file attachment
> prepared for transmission using the Internet MIME message format. If you
> are using Pegasus Mail, or any other MIME-compliant system, you should be
> able to save it or view it from within your mailer. If you cannot, please
> ask your system administrator for assistance.
>
> ---- File information -----------
> File: Button2UpLocation.zip
> Date: 24 Apr 2015, 10:50
> Size: 5229 bytes.
> Type: ZIP-archive
> _______________________________________________
> Cuis mailing list
> [hidden email]
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

Dan Norton

Re: mouseButton2Up:localPosition:

On 27 Apr 2015 at 8:10, Juan Vuletich wrote:

> Hi Dan,

> So, where's the bug? It's in your #mouseButton2Up:localPosition: .

> You get

> a point in local coordinates (you can check this bu just adding

> 'localEventPosition print'). And you ask for the menu to open there.

> But

> the menu is not a submorph. It will be a submorph of the world.

> (this is

> again easy to check by opening an inspector on the menu, by doing

> 'self

> inspect').

Interesting. Please allow me to state my understanding of the case. When writing code for a Morph subclass, it's easy to assume that the "localPosition" refers to that of the receiver and it does. But PopUpMenu inherits from Object rather than Morph and when told to position itself 'at: localPosition', PopUpMenu has the display screen as its reference and interprets localPosition accordingly.

> What you want is, instead of just using 'localEventPosition' to use

> '(self

> externalizeToWorld: localEventPosition)'.

#externalizeToWorld: transforms the parameter from the coordinates of self to the coordinates of the display screen. Using this as the location for PopUpMenu will cause it to appear over the top morph where the click occurred - the receiver.

Your alternative

> #xmouseButton2Activity is perfectly fine too.

This gets "right to the point." Is this sent from MouseClickState>handleEvent:from: ?.

I hope I got all this right.

- Dan

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

Juan Vuletich-4

Re: mouseButton2Up:localPosition:

Hi Dan,

On 4/29/2015 11:45 AM, Dan Norton wrote:

On 27 Apr 2015 at 8:10, Juan Vuletich wrote:

> Hi Dan,

>

> So, where's the bug? It's in your #mouseButton2Up:localPosition: .

> You get

> a point in local coordinates (you can check this bu just adding

> 'localEventPosition print'). And you ask for the menu to open there.

> But

> the menu is not a submorph. It will be a submorph of the world.

> (this is

> again easy to check by opening an inspector on the menu, by doing

> 'self

> inspect').

>

Interesting. Please allow me to state my understanding of the case. When writing code for a Morph subclass, it's easy to assume that the "localPosition" refers to that of the receiver and it does. But PopUpMenu inherits from Object rather than Morph and when told to position itself 'at: localPosition', PopUpMenu has the display screen as its reference and interprets localPosition accordingly.

Well, no. The position of a morph is expressed in the coordinate system of the owner, i.e. the morph containing it. The morph getting the event gets the mouse position in its own coordinates. But it doesn't add the Menu as its submorph: the menu is added as a submorph of the world. Therefore, the position must be expressed in world coordinates.

> What you want is, instead of just using 'localEventPosition' to use

> '(self

> externalizeToWorld: localEventPosition)'.

#externalizeToWorld: transforms the parameter from the coordinates of self to the coordinates of the display screen. Using this as the location for PopUpMenu will cause it to appear over the top morph where the click occurred - the receiver.

In my experiment, doing 'self externalizeToWorld: localEventPositon' made the menu open exactly under the mouse pointer. Wasn't this the case for you?

Your alternative

> #xmouseButton2Activity is perfectly fine too.

>

This gets "right to the point." Is this sent from MouseClickState>handleEvent:from: ?.

I hope I got all this right.

- Dan

If you want to see where stuff is called from, add 'self halt' at that point. Doing this in Morphic code sometimes is risky, as it might result in an infinite sequence of debuggers opening. Doing 'thisContext printStack: 10' is safer.

Cheers,
Juan Vuletich

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

Dan Norton

Re: mouseButton2Up:localPosition:

On 1 May 2015 at 15:55, Juan Vuletich wrote:

>
> Hi Dan,
>
> On 4/29/2015 11:45 AM, Dan Norton wrote:
> On 27 Apr 2015 at 8:10, Juan Vuletich wrote:
>
> > Hi Dan,
> >
> > So, where's the bug? It's in your
> #mouseButton2Up:localPosition: .
> > You get
> > a point in local coordinates (you can check this bu just
> adding
> > 'localEventPosition print'). And you ask for the menu to open
> there.
> > But
> > the menu is not a submorph. It will be a submorph of the
> world.
> > (this is
> > again easy to check by opening an inspector on the menu, by
> doing
> > 'self
> > inspect').
> >
> Interesting. Please allow me to state my understanding of the
> case. When writing code for a
> Morph subclass, it's easy to assume that the "localPosition"
> refers to that of the receiver and
> it does. But PopUpMenu inherits from Object rather than Morph
> and when told to position
> itself 'at: localPosition', PopUpMenu has the display screen as
> its reference and interprets
> localPosition accordingly.
>
> Well, no. The position of a morph is expressed in the coordinate
> system of the owner, i.e. the
> morph containing it. The morph getting the event gets the mouse
> position in its own coordinates.
> But it doesn't add the Menu as its submorph: the menu is added as a
> submorph of the world.
> Therefore, the position must be expressed in world coordinates.
>

Ah, the owner of the pop-up is the PasteUpMorph called [world].

> > What you want is, instead of just using 'localEventPosition'
> to use
> > '(self
> > externalizeToWorld: localEventPosition)'.
>
> #externalizeToWorld: transforms the parameter from the
> coordinates of self to the
> coordinates of the display screen. Using this as the location
> for PopUpMenu will cause it to
> appear over the top morph where the click occurred - the
> receiver.
>
> In my experiment, doing 'self externalizeToWorld: localEventPositon'
> made the menu open
> exactly under the mouse pointer. Wasn't this the case for you?
>

Yes, under the mouse and over the morph :)

> Your alternative
> > #xmouseButton2Activity is perfectly fine too.
> >
>
> This gets "right to the point." Is this sent from
> MouseClickState>handleEvent:from: ?.
>
> I hope I got all this right.
>
> - Dan
>
>
> If you want to see where stuff is called from, add 'self halt' at
> that point. Doing this in Morphic
> code sometimes is risky, as it might result in an infinite sequence
> of debuggers opening. Doing
> 'thisContext printStack: 10' is safer.
>

Great. I'll try that. The red blizzard is no fun.

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

Dan Norton

Re: mouseButton2Up:localPosition:

In reply to this post by Juan Vuletich-4

On 1 May 2015 at 15:55, Juan Vuletich wrote:

[snip]

>
> Your alternative
> > #xmouseButton2Activity is perfectly fine too.
> >
>
> This gets "right to the point." Is this sent from
> MouseClickState>handleEvent:from: ?.
>
> I hope I got all this right.
>
> - Dan
>
>
> If you want to see where stuff is called from, add 'self halt' at
> that point. Doing this in Morphic
> code sometimes is risky, as it might result in an infinite sequence
> of debuggers opening. Doing
> 'thisContext printStack: 10' is safer.
>

Actually, 'self halt' was OK in the case of my #mouseButton2Activity method. The identity of
the sender is Morph which sends it on button 2 *down* not 'up' as I had assumed. I had
hoped to learn how using #mouseButton2Activity makes correct location of a pop-up easy yet
#mouseButton2Up:localPosition: not so easy but that is TBD.

- Dan

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org