VI property subpanel ref

[wiebe@CARYA]

Not sure why I can't find this idea, there are a few 'VI Ref' read property for SubPanels" posts, but couldn't find this one...

How about a VI property "SubPanel" , that returns the subpanel a VI is in (or Not a ref)?

Now I have to give all dynamic VI's a SubPanel reference, and when started, and put into a subpanel, I have to dynamically set the control value. I need the subpanel reference, for coordinate conversion, handling tabbing, getting panel images, etc.

Regards,

Wiebe.

[wiebe@CARYA]

Aristos,

Not going into everything here, most of your reply is caused by the escalating discusion, at least partially caused by myself. I do agree to your remarks, it's just not applicable to my situation. Obviously I did not explain my situation clearly.

I'll just have some questions about these parts of our reply.

>I'm not putting this idea on the list of ideas we should consider closing.

I'm not sure what that means. Is this an official label?

>But I would be surprised if this gets enough kudos to overcome severe architecture reservations.

Yeah, it's not very likelly get much kudos. The lengthy read of the comments won't help.

What exactly is enough kudos? (Probably  "It depends", but I'll try it anyway)

With "severe architecture reservations" you mean you are still worried this will be misused? I'm still not seeing how this would trigger people to create evil architectures. (We have shared variables for that).

[wiebe@CARYA]

Aristos,

Not going into everything here, most of your reply is caused by the escalating discusion, at least partially caused by myself. I do agree to your remarks, it's just not applicable to my situation. Obviously I did not explain my situation clearly.

I'll just have some questions about these parts of our reply.

>I'm not putting this idea on the list of ideas we should consider closing.

I'm not sure what that means. Is this an official label?

>But I would be surprised if this gets enough kudos to overcome severe architecture reservations.

Yeah, it's not very likelly get much kudos. The lengthy read of the comments won't help.

What exactly is enough kudos? (Probably  "It depends", but I'll try it anyway)

With "severe architecture reservations" you mean you are still worried this will be misused? I'm still not seeing how this would trigger people to create evil architectures. (We have shared variables for that).

[Intaris]

Regarding the global cursor position solution, would the following not achieve what you need?

Snippet appears to be  broken (That STOP vutton should not be there, and perferably the VI would not be broken), but I think you can see what it does.  I tested it in a sub-panel and since it used an OS call to get the mouse position it seems to work even in a sub-panel.

Shane.

[wiebe@CARYA]

Shane,

It would work, but it doesn't feel good to me at all. Does this work when the cursor controller is not a mouse? Not sure if that is possible.

Could also get the result with one API call GetCursorPos but it's still smelly.

Anyway, I'm not really looking for a solution, but for arguments for getting a SubPanel property for a VI Class.

[Intaris]

I haven't tried it on a touch-panel but I'm pretty sure it returns the coordinates of the system pointing device (i.e. Mouse or touchpad or touch screen).  If the device can click and drag, I'm pretty sure the mouse Input VIs will do the job.

Regarding the example, Our feelings of what feels good vary greatly.  Even if you had code to get the subpanel continer reference in which the VI is placed, there's still a time lapse between the moment you click and the moment you are able to calculate the proper position on the screen.  By then it's feasible (although highly unlikely) that the sub-panel or the master VI will have changed state due to external actions thus rendering the coordinate calculation somewhat stale.  A better approach would perhaps to extend the returned data of the mouse events to include not just relative mouse coordinates but also absolute screen coordinates.

I know you're trying to find reasons for a subpanel reference for any given VI but I'm unsure there's enough of a supporting case to warrant it, thus my suggestion for alternate code to achieve the same functionality.  You want code which is independent of whether a VI is in a sub-panel or not.  This does that.  You want the sub-VI to be able to find this information without loading the master VI with extra functionality.  This does that.

I'll make the suggestion that it's currently possible via object traversal to actually find what you are looking for using currently implemented methods.  I'll try to get a sub-VI to do this but I think you already know how to do this.  Why is that not sufficient?

[Intaris]

I've managed to create some code which uses existing VI Server calls to get a reference to the parent SubPanel for a given VI but it seems to create a lot of problems in LV 2012.

Although I CAN get the reference, the system behaves weirdly.  Once the code for finding the subpanel is finished, the code continues to run but the FP of the inserted VI becomes completely unresponsive.  I can no longer click on any buttons......  I don't know if I've made a mistake with closing references or whatever but as it currently exists it seems that something somewhere doesn't like what I'm doing.

The code itself is not the fastest I'll freely admit.  Although it may require significantly more work to get the reference then the proposed property, I see no reason (barring my oversseing something) why it shouldn't work.

It seems that the VI thinks it's still within the subpanel even after the VI hosting it has removed it and is closed.  This leads to a zombie VI in memory.  I can't even stop it with "All VIs in Memory" and then "Abort".

[wiebe@CARYA]

>I'll make the suggestion that it's currently possible via object traversal to actually find what you are looking for using currently implemented methods.  I'll try to get a sub-VI to do this but I think you already know how to do this.  Why is that not sufficient?

It's not sufficient because it won't always work. See numbered item 8).

The code itself is not the fastest I'll freely admit.  Although it may require significantly more work to get the reference then the proposed property, I see no reason (barring my oversseing something) why it shouldn't work.

Because you are traversing all VI's, but can't  Traverse clones because you can't get references to them.

It seems that the VI thinks it's still within the subpanel even after the VI hosting it has removed it and is closed.  This leads to a zombie VI in memory.  I can't even stop it with "All VIs in Memory" and then "Abort".

It is sometimes problematic when a caller inserts a VI into a subpanel, then the VI stops, and the parent removes the VI. I don't know the exact sequence that causes the problem, but. I've seen it before.

It helps if you make the VI inside the subpanel remove itself, and then stop. But you do need a reference to the subpanel.

[wiebe@CARYA]

Regarding the example, Our feelings of what feels good vary greatly. 

It should also work on MacOS.  I prefer LabVIEW functions over VI's use external code,.

Even if you had code to get the subpanel continer reference in which the VI is placed, there's still a time lapse between the moment you click and the moment you are able to calculate the proper position on the screen. 

The sequence of 3 API calls you suggest takes 0.15 ms on my computer (average of 10000). The two property nodes take 0.05 ms. I do not do any calculation myself.

The coordinates that where clicked are what I am after, not the coordinates more then 0.15 ms later. More then 0.15 ms, becuase there is no telling how long it took the event structure to handle the actual event. There could been any number of events before the click.

What if you want coordinates local to the master VI?

By then it's feasible (although highly unlikely) that the sub-panel or the master VI will have changed state due to external actions thus rendering the coordinate calculation somewhat stale.  A better approach would perhaps to extend the returned data of the mouse events to include not just relative mouse coordinates but also absolute screen coordinates.

That would be nice.

What if you want coordinates local to the master VI?

[Intaris]

Regarding the 0.15ms.....

USB HID specification allows a maximum response rate from a HID of 1ms per packet.  Faster is not possible. Therefore it's not possible to have the system pointer move position within a 1ms window.  Even then, only gaming mice tend to make use of this high rate.  Most consumer HIDs use a polling rate of 5ms or slower.

But I understand your sentiment, hence the proposal that a modification to the coordinates returned by the built-in LV function would be the only way to go.

BTW:

The coordinates that where clicked are what I am after, not the coordinates more then 0.15 ms later. More then 0.15 ms, becuase there is no telling how long it took the event structure to handle the actual event. There could been any number of events before the click.
This disqualifies your approach along with mine.  Simply having the sub panel reference will not save you from this lag and getting possible incorrect mouse coordinates.  It's still going to be an "after the act" operation.

[wiebe@CARYA]

This disqualifies your approach along with mine.  Simply having the sub panel reference will not save you from this lag and getting possible incorrect mouse coordinates.  It's still going to be an "after the act" operation.

I do not care about the mouse position when processing the event, I want the coordinated that a user clicked on. The coordinates are put on the event stack when the click occures, and no matter how long it takes to process the event, the coordinates will not change. The popup will appear where the user clicked  This are the correct mouse coordinates.

[Intaris]

OK now we're talking about two different things.  Are you intending registering for mouse events on the subpanel reference?  What if the VI is removed from the subpanel?  What if it is inserted to a different one?  How do you keep the event refnum up to date?

My point is that your calculation from local to global coordinates after you have the correct and coherent local click coordinates assumes that all steps involved in that calculation do not change during the time of calculation, that no window changes size, that the VI remains in the sub-panel and so on.  Therefore the lag between generating the event and reaching the final translated coordinates is not foolproof.

To be honest (We're being blunt, right) the discussion is getting rather long-winded.  You gave an example of mouse coordinates of a VI which may or may not be in a sub-panel (and linked to a forum post on the subject) and now say you're not interested in the mouse coordinates.  I'm having trouble working out exactly what it IS you're interested in.  You claim the evene mouse coordinates are correct.  Where does the translation of coordinates come into this at all?