xControl Facade VI/Panel Reference

[WireStraits]

For unspecified reasons, I want to be able to resolve which control has been clicked on from a pane mouse down event.  Our application is somewhat large and makes extensive use of sub-panels, so registering every control individually, statically or dynamically, would be a lot of work, maybe not very efficient, and would require ongoing resource tracking once registered, so the pane mouse down event in a top level VI would be preferred.

I've written a VI that takes a pane reference and pane coordinates (hypothetically from a mouse down event) and resolves the first, if it exists, control that resides on that pane and contains those coordinates within its bounds.  The VI also considers the control class, and if it is a subpanel, gets the inserted VI, it's panel, and any pane that contains the coordinates and recurses.  In this manner, the VI traverses arbitrarily deep nested subpanels until it gets to the control that was clicked on.

This is where it gets (more) complicated.  I also want to traverse xControls.  When a control within an xcontrol is clicked on, I want the reference to the (sub?) control, not the xcontrol.  It is simple enough to detect whether a control is in fact an xcontrol, but apparently more challenging to get any more information than that.  So my questions are these:

From an control reference where IsXclt=T, is there a way to get a reference to the xcontrols panes or some owner (panel, facade vi, clone name)?  I realize I could do this by setting a custom property of the xcontrol, but then it would not be generic to xcontrols and would again require sprawling coding effort.

or

Is there an entirely different and simpler way to achieve what I am proposing in the first paragraph?

This is in LV2012sp1 btw.

Thanks for reading; any help or suggestions would be appreciated!

[Eric.M]

There's no easy way I know of to retrieve the XControl subpanel reference in the calling VI.

I'd rather go with a user event containing the XCtrl pane reference+coords of click, that would be generated from the "Pane: Mouse down" event case of the Facade VI. Register your event in the calling VI to get your data the way you do for the other type of GObjects.

Sounds like a pain, heh.

Taking a step backward, XControls are a type of controls, which is why everything is done in order to avoid considering the single XCtrl components from the caller perspective.

Regards,

--Eric

[Intaris]

XControls are also libraries which enforce a certain encapsulation.  I'm assuming this is for an edit-time operation and not a run-time operation?

[WireStraits]

It is in fact for run-time operation.  We most often use xControls as modular multidemensional input where reconciliation is needed to prevent forbidden input.  If the same style input is needed in a new part of our application, instead of replicating the code needed to forbid forbidden input, we drop in the xControl and let it handle it.

Our application also detects every mouse down event and opens or closes an on-screen keyboard as needed.  If an enabled control was clicked on, open the osk, else, close.  However, we sometimes open a special number pad for numeric controls.  This is basis for wanting to interpret the xControl as component controls, as you can imagine complex input might have both string and numeric components.

I knew I was stretching the limits of what xControls are intended for, but I am somewhat disappointed that NI hasn't made run time access to xControl components possible, considering how useful it would be in this one exceedingly esoteric instance, and possibly several others, encapsulation impositions notwithstanding.

Thanks anyway for the review; we'll figure something out.