Screen position of control in nested subpanels

[lucian.grec]

I'm having trouble figuring out the coordinates transformation to go from the innermost control's local position to the outermost subpanel position and then to the screen coordinates. I'm attaching a test VI that I use to test this. I got it to work with 1 nested subpanel but it requires some magic constants which leads me to think that I'm doing something wrong somewhere, and it breaks apart when adding another nested subpanel.

Does anyone know what I'm missing? Open Untitled.1. The other VIs are all nested in it.

[Bob_Schor]

This does not directly answer your question, but maybe will make it moot

First, most of the routines that I run in a sub-Panel are configured so that when they run, their entire "visible" Front Panel exactly "fits" within the sub-Panel, so (for the most part) I never have to think about "screen coordinates" or the position of the controls in the VIs showing on the sub-Panel. 

I make the sub-Panels, when they start, "resize themselves" as necessary by using a tool from the OpenG set of tools found in VIPM (which have been around for around two decades!) called "Fit VI Window to Largest Dec" (the "oration" has been left out of the name).  I go to my "VI to be displayed" and put a "Decoration" (often a Flat box) around it, lining it up with the Grid, and setting the sub-Panel to the same Grid size.  Make this VI the first thing that runs in your sub-Panel code and it will simply "fit right in"

I also tend to start them by inserting them first into the sub-Panel, then starting them either by explicitly calling them or starting them using "Start Asynchronous Call", sometimes stopping them by pushing the "Stop" control on the sub-Panel's Front Panel.  On other occastions, I've had a half-dozen Asynchronous Routines running simultaneously, and used a Top-Level Control to decide which one to display in the sub-Panel (and letting me choose another, in which case it closed the sub-Panel and re-populated it with the new request, using a different mechanism to stop all of the sub-Panel routines when the program ended).

I think nesting sub-panels any deeper is likely to be a nightmare-to-be-avoided ...

Bob Schor 

[lucian.grec]

I'm trying to automate r.click menus and such in LabVIEW. The software I'm trying to automate uses in some cases nested subpanels and I'm trying to find a general solution to the problem of r.clicking on various controls. I want the user of this framework I'm writing to be able to just r.click on a control identified by it's label rather than having to provide coordinates for it.

[Bob_Schor]

One of us (probably I) is missing the point.  If your sub-Panel shows a control of the sub-VI running in the sub-Panel (no matter how deeply nested), the sub-VI will be in a position to respond via a "Value Changed" Event (or by simply repeatedly reading the control, such as "Stop", and responding to it).  I've told you how to (with little effort on your part) to make a sub-VI "automatically" place itself (by, at run time, resizing itself to a "known size" designed to be the size of the sub-Panel, hence with all its controls visible).  What more do you need?  If you can "see" the Control, you can interact with it (or "click on it").  Maybe an example would help me understand.

Bob Schor

[JÞB]

---

@lucian.grec wrote:

I'm trying to automate r.click menus .... in LabVIEW. ...  I'm trying to find a general solution to the problem of r.clicking on various controls

I want the user of this framework ....to be able to just r.click on a control identified by it's label rather than having to provide coordinates for it.

---

Now you have confused me too!  So let me ask a question. Are you attempting the equivalent of a "LabVIEW Netbot?" If so, you'll get 👎

User input is USER input!  

Alternatively,  you might be confusing me with your use of "the user" when you mean "the developer" applying your framework.

Help us help you. 

[lucian.grec]

Yes the User will eventually be our testing team that will have to write automated tests for the UIs. I want them to be able to have a clean API in python that would allow them to do left_click(ui_name = 'Main', ctrl_name='Start'). I'm using the user32 dll to simulate the mouse click on that control so for that I need it's exact position on the screen. I can manage to get it just fine if the user interface is simple enough but I'm finding it difficult/impossible to get that from within subpanels/nested subpanels.
I'd prefer not going down the route of having to specify mouse coordinates because it'll make the tests harder to read, since there's no link between the mouse coordinates and the control name.

[wiebe@CARYA]

It would help if you could get a reference to the subpanel the VI is in... Then you could use pane to panel\ panel to screen methods.

But that's a terrible idea: VI property subpanel ref - NI Community.

[lucian.grec]

I don't have a problem with the references part. I have a problem with the math I have to do to get the coordinates right in the screen coordinates or at least the top level VI hosting the subpanels + control in one of them. I've attached an example to the initial post that works for 1 subpanel but not for multiple nested ones. Imo it should work, logic behind it being a coordinate system transformation from one to the other until you reach the end, and since it works for 1 transformation it should work recursively as well but it doesn't.

[Yamaeda]

The Panel.bounds gives screen coordinates, so that + control position should give screen position regardless of subpanel level.

[wiebe@CARYA]

---

@lucian.grec wrote:

I don't have a problem with the references part. I have a problem with the math I have to do to get the coordinates right in the screen coordinates or at least the top level VI hosting the subpanels + control in one of them. I've attached an example to the initial post that works for 1 subpanel but not for multiple nested ones. Imo it should work, logic behind it being a coordinate system transformation from one to the other until you reach the end, and since it works for 1 transformation it should work recursively as well but it doesn't.

---

It depends a lot on which coordinates you get as an input.

Properties and events can return either control coordinates (picture control), pane coordinates (pane mouse move) or panel coordinates (panel mouse move).

You might need more math, to do the math for your exact situation. 

The PanelToScreenCoords needs to be done with the top level VI, and then it should work PanelToScreenCoords should convert local pane\panel coords to screen:

This does require two things: 1) you need to know if the VI runs in a subpanel, 2) you need the reference of the top level subpanel's VI. That's where the idea exchange idea would help, you wouldn't need to propagate the VI ref of the main.