How to get an object's on-screen position in a multipane VI

[David_Staab]

REV 2 UPDATES BELOW:

I'm developing a simple UI that provides a table for data entry. I wrote a little pop-up window that provides autocomplete behavior for any cell, but I need to figure out how to position that window directly beneath the cell being edited. As LabVIEW's documentation does not clearly explain how the Position, Master Bounds Rectangle, Total Bounds Rectangle, Origin, Content Rectangle Position, and several other properties related to on-screen position work with each other, this has proven to be a frustrating experience.

I'm able to get the pixel position of the lower-left corner of the cell currently being edited, with respect to the upper-left corner of the table's entire bounding rectangle (including all labels and decorations) using this:

And I can find the pane that contains the table (among several panes on the VI's panel) using this:

But the "position" repoted by the pane looks like it's just the position of the top-left object on that pane. It certainly isn't the position of the pane within the panel.

Can anyone help me figure out the rest of the steps toward getting the position of the edited cell on the screen? I imagine I need to get the pane's position in the VI, then the VI's position on the screen.

I've attached the VI I'm playing with for reference.

==============================

REV 2

=====

I'm closer after Norm's suggestion. I updated the attachment with a new (cleaner) example and a full-screen screenshot for comparison. The Left value is correct, but I'm 91 px of on the Top value. (Remember that "Top" is the top of the pop-up window that will display beneath the cell being edited.) Any more ideas?

[NJKirchner]

Something like this

Pane.Master Bounds Rect will get you the position of the pane relative to the window

add your cell position

add the FP.PanelBounds and your off to the races

Enjoy

~,~

[David_Staab]

I found the culprit of the vertical discrepancy in rev 2: "Front Panel Window.Panel Bounds:Top" is incorrect when Windows Aero is enabled.  "Front Panel Window.Window Bounds:Left" is correct, though.

Is this a bug in LV, or is there a known adjustment I should be applying to the value? And if that's the case, how do I tell whether Aero is enabled so I can decide whether to apply the adjustment?

Edit: Fixed a typo.

[Christina_R · Accepted solution]

I do not see the behavior you describe with the Front Panel Window.Panel Bounds property on my Windows 7 machine - the values are consistent (and appear to be correct) whether or not Aero is enabled. I may need more information about your system.

I'm not sure why you are using Scripting properties to try to accomplish your task, as none are necessary. Also, the comments seem to indicate you're confused about the LabVIEW coordinate systems - position properties are not "offset from corner" they are "offset from origin." (I know this is confusing and have been working on a blog topic about it, which I hope to post soon). [Edit: Sorry, I just realized you have your pane origins positioned at the corners, so these are, in fact, the same for you. Probably best not to confuse others who read your code, though].

Here is an example of how to do the coordinate transformations you need. Let me know if you want me to e-mail you the VIs.

Hope this helps.

[David_Staab]

Thanks for glancing at this, Christina.

I'm not sure why you are using Scripting properties to try to accomplish your task, as none are necessary...Here is an example of how to do the coordinate transformations you need.

I didn't know about the "Convert X to Y Coords" methods. That makes life much easier for this particular task. What is the subVI in your screenshot? It's unlabeled, and I don't recognize it from the icon.

I see that you get Table:Owning VI --> Owning VI:Panel, whereas I get Table:Owner (which is already a Panel). Am I ever not guaranteed to get a Panel as the Table's owner? If I am  then why ever open a reference to the VI just to get the panel when I can go straight to the panel instead?

(Aside: The LV "box model" -- if I may borrow a term from CSS and general graphic design -- looks like VI:Panel:Panes:Controls. Then why is the Owner of a Control always a Panel and not a Pane?)

Also, the comments seem to indicate you're confused about the LabVIEW coordinate systems - position properties are not "offset from corner" they are "offset from origin." (I know this is confusing and have been working on a blog topic about it, which I hope to post soon). [Edit: Sorry, I just realized you have your pane origins positioned at the corners, so these are, in fact, the same for you. Probably best not to confuse others who read your code, though].

Okay, now I know that "coordinates" := "offset from Origin". Some comments that might be used as product feedback:

• That's something neither stated nor implied in the Context Help for many properties. Indeed very confusing for a novice who has to rely on LV Help and Context Help to put this code together.
• Likewise, Pane:Origin's help says it gives the "coordinates of the upper- left corner of the pane": since coordinates are defined by the origin, it's really confusing to circularly define the origin by the coordinates of something else.
• Finally, splitters don't belong to a Pane but a Panel, yet Splitter:Splitter Position's help says it's the "coordinate" of the left or top of the splitter...that would mean an offset from an origin...but the splitter's owner (a panel) doesn't have a defined origin.
• I think a simple diagram of the "LabVIEW Box Model" defining containers and dimensional properties would be immensely helpful as an amendment to the LV Help or online documentation.

I do not see the behavior you describe with the Front Panel Window.Panel Bounds property on my Windows 7 machine - the values are consistent (and appear to be correct) whether or not Aero is enabled. I may need more information about your system.

Hmm...well looking at the screenshot I attached with my code, the actual coordinate of the desired pixel is in fact 91 px higher than what the code reports. So something is still wrong with the code I put together, and from what I undertstand, nothing should be. It's just a less efficient way of arriving at the same value, isn't it? Then where's the bug? I can share whatever system information you need; it's just a Win 7 x64 virtual machine I use as a development scratchpad.

[Christina_R]

DavidStaab wrote:

What is the subVI in your screenshot? It's unlabeled, and I don't recognize it from the icon.

Oh, sorry - that's just a little helper VI to move a rectangle to a point:

[Christina_R]

DavidStaab wrote:

I see that you get Table:Owning VI --> Owning VI:Panel, whereas I get Table:Owner (which is already a Panel). Am I ever not guaranteed to get a Panel as the Table's owner?

If the Table is in any kind of container object, then the owner would not be the panel. For example, if the table was in a tab control, the owner would be a tab control page.

[Christina_R]

DavidStaab wrote:

(Aside: The LV "box model" -- if I may borrow a term from CSS and general graphic design -- looks like VI:Panel:Panes:Controls. Then why is the Owner of a Control always a Panel and not a Pane?)

This is unfortunate historical cruft. The "Owner" property for a control existed before LabVIEW had panes and, for backward compatibilitity, the owner property was made to ignore panes when panes were introduced.

[Christina_R]

DavidStaab wrote:

Okay, now I know that "coordinates" := "offset from Origin". Some comments that might be used as product feedback:

• That's something neither stated nor implied in the Context Help for many properties. Indeed very confusing for a novice who has to rely on LV Help and Context Help to put this code together.
• Likewise, Pane:Origin's help says it gives the "coordinates of the upper- left corner of the pane": since coordinates are defined by the origin, it's really confusing to circularly define the origin by the coordinates of something else.
• Finally, splitters don't belong to a Pane but a Panel, yet Splitter:Splitter Position's help says it's the "coordinate" of the left or top of the splitter...that would mean an offset from an origin...but the splitter's owner (a panel) doesn't have a defined origin.
• I think a simple diagram of the "LabVIEW Box Model" defining containers and dimensional properties would be immensely helpful as an amendment to the LV Help or online documentation.

I knew our documentation was unclear in this area, but I'm just now getting appreciation for how much improvement is needed.

When I said "origin" I meant the (0, 0) point in a coordinate space. Unfortunately, that's not how the "origin" property is defined in LabVIEW, so I will need to disambiguate.

I have been wanting to find a way to clarify the coordinate systems in LabVIEW for some time and this seems like a good opportunity to work on that. Let me put together some pictures.

[Christina_R]

DavidStaab wrote:

So something is still wrong with the code I put together, and from what I undertstand, nothing should be. It's just a less efficient way of arriving at the same value, isn't it? Then where's the bug?

I'd have to spend more time examining your VI to be certain, but I don't think your approach is the right algorithm. You're using position values as offsets, which only works if the (0, 0) point happens to be in the top-left corner of the space you expect. In particular, I'm not sure what the "Master Bounds Rect" scripting property is using for its coordinate system and I suspect your assumption is not holding in all cases there.