Hello.

I'm trying a GUI abstraction that can highlight certain elements when mouse cursor hovers over them. What I need is a way to determine mouse coordinates relative to my abstraction's GOP bounding box, regardless of how many subpatches deep my abstraction is.

I'm thinking of using a set of [iemguts/receivecanvas] objects to get "motion" messages for parent canvases of up to a certain level up, combined with a set of [iemguts/canvasposition] objects to determine position of each canvas within its parent.

Do you guys know a better way of doing this?

That's the best way so far as I know. You can also use a cnv object and a "get_pos" message to find the position, but this is basically the same as [canvasposition]. Unfortunately, both objects need to be banged with a metro, generating a whole stream of data, so you should definitely use the [change] object.

Once you have the real position, I would recommend doing something like this:

This reduces the resolution of the x-y coordinates, so that the coordinates 1,1 to 10,10 all fall under a box called "1,1" This way, you have a list that you can route easily, rather than having to mess around with conditional logic. You can change the resolution by choosing a different creation argument for [div].

@LiamG, can you elaborate on how get_pos can be used here? I don't know where I can learn more about it. Are you suggesting that I add a [cnv] object into each nested subpatch in order to track the coordinates? I could do that but I was hoping to make a universal abstraction that can be put into any other abstraction or subpatch and and it'll work with no additional setup. I doubt it'd be reasonable to ask every user of my abstraction to put a special [cnv] object into every level of subpatch hierarchy.

By the way, looks like [iemguts/receivecanvas] path is not gonna work too since it reports coordinates relative to the GOP area (I assume) but I don't know a way to get size/position of the GOP area of parent canvases.

Geez, why does everything have to be so complicated...

Sorry, I meant to say that [iemguts/canvasposition] returns coordinates relative to parent window's top left corner instead of the top left corner of the GOP area. So it's impossible to translate the mouse position from parent window's coordinate system to the child window.

@lzr As you know the position of the canvas on the parent and you know the size of the gop you could calculate the position of the mouse within the child and send the coordinates back (only when the mouse is over that window) and have the child background color change.
And probably you only need to get the childs position once (on opening the patch) and so you can avoid the metro that @Liam mentioned......
David.

Not impossible! If you take the [receicecanvas] data, which is relative to the parent canvas, and subtract the [canvasposition] or [get_pos( data, you will get the mouse position relative to the abstraction instance.

The [get_pos( method only requires one canvas placed in the abstraction to work. You can find out how to use it in the cnv help file, under "edit". I seem to remember finding some reason why this worked better than [canvasposition], but I can't remember what it was. In theory, [canvasposition] should do exactly the same thing.

@lzr Here is the edit thingy that Liam and I are talking about........ try making the K1 and K2 in the pd room object change colour when the mouse is over them...... and you are there!
parent.pd
David.

Sorry, guys, but I think you're missing my point on what I'm trying to accomplish.

There's no single parent canvas. There can be multiple parents. And my GOP abstraction should work regardless of how many parents it has and which of the parent windows is visible.

Let's consider an example. We have a patch called patch.pd (not created by me, but by the user of my abstraction). Inside patch.pd there's a GOP subpatch: [pd $0-level1] (position and size of GOP area are arbitrary). Inside it there's my GOP abstraction [myhovertest].

Now, if I use [iemguts/canvasposition 2] in myhovertest.pd, it's going to return the position of $0-level1 relative to the top right corner of the main patch. So if we subtract this position from mouse position that we got from receivecanvas, we can get the position of the mouse relative to $0-level1's GOP area. The issue is, there seems to be no way of determining the position of GOP area programmatically, so we have no way of knowing where the mouse is relative to our abstraction [myhovertest]. [iemguts/canvasposition 1] returns position of [myhovertest] relative to $0-level1's window, but what we really need to know is the position of [myhovertest] relative to $0-level1's GOP area.

I hope I explained this well...

@lzr
So as your client will be working on their own top level patch you need your abstraction to report to a patch over which you have absolutely no control. And at the same time you do not have window focus.......
You could maybe tell it where it should be, rather than asking, as it is created?
goppy stuff.zip
Open "master" and in [goppy] you will see the messages being sent. There will be a way to tell "hover" where it should be and what its size should be on its parent......... whether it should show it's name etc. Not all of it seems to work, but enough of it does.
But it cannot know whether the mouse is "hovering"........... so give up straight away!!!!!!
However........ look at this.........!
hover.pd
You could modify [pointer_position] (its an abstraction luckily) for your purposes and then hide it. You would have to force your abstraction to "open" itself as a window, and suppress the menu, but it would know when the mouse is "hovering", and such things are possible.
More research needed.......
So it seems that "motion" messages, (or in fact all messages) are being received from a window depth of your choice........ I think that should help.......!...........at least for the original question.....
hover.zip and watch your terminal.......
David

Not available yet, but I've got some event handlers for data structures in the upcoming release of pd-l2ork.

[loadbang]
|
[mouseover 1, mouseout 1(
|
[draw rect 0 0 40 40]
|
[print]

A scalar that uses that drawing command will send a message to the outlet any time the mouse moves into or out of the scalar, whether it's on the main canvas or in a GOP.