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]

OK now we're talking about two different things.  Are you intending registering for mouse events on the subpanel reference? 

No. The VI inside the subpanel registers for pane mouse down.

What if the VI is removed from the subpanel?

I know for a fact that that does not happen. At least not in my design. I know because only the plug in will remove itself from the subpanel. Remember clones are not removed from memory when removed after they stopped?

What if it is inserted to a different one? 

That whould happen through user event, and that events will be handled after the pane mouse down event.

How do you keep the event refnum up to date?

That's not an issue. Am I right that this question does not make any send given the answers above?

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. 

Again, this will all happen in the same event pipeline, and therefore I know a window size change happening before the mouse down will be processed after the mouse down event.

Hard to belief, I'm sure. All windows in this app have a custom windows look. Even the borders need to look different. So all VI borders and title bars, etc. are removed (an empty square canvas remains), and they are replaced by my own border and title bar decorations. Sizing is done by overlaying a 99% transparent VI with the same dimensions as the real window. This VI is sizable. When it is resized, the master changes it's size though a user event, and that causes all subpanel plugins to get a pane resize event. A click and a resize always follow in the right order. Same goes for closing, and changing plug in.

I told you I take on the weirdest challanges. If I did not, I'd be making pilot plants and DAQ apps day in day out. When a customer wants to pay me for making the impossible, I grab the challenge with both hands.

Therefore the lag between generating the event and reaching the final translated coordinates is not foolproof.

I've not seen it fail jet. I think it is.

I do admit that this is a very specific situation.

To be honest (We're being blunt, right) the discussion is getting rather long-winded. 

I'll reply to this after the bar. It's better suited as ending.

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?

The coordinates are correct, in the sence that they provide the information I am interessed in. They just need to be converted.

in contrast, the device interface VI give the wrong information (the current mouse position not the clicked mouse position), but they are screen coordinates so would not need conversion.

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 am interested in the mouse coordinates of a mouse click. Not in the current mouse coordinates. I can see how this is confusing, i though the diffence was clear from the context of the remark. The device interface gives the mouse coordinates [of the current position] while I am interested in the [mouse coordinates of the] click position.

---

---

To be honest (We're being blunt, right) the discussion is getting rather long-winded. 

Don't hold back on by account. I have a think skin. I don't mind long winded discussions myself. Weekend started, I was longing for a beer since you mentioned it.

Even if I can convince you (which is unlikelly), the thread will have two kudo's at time of writing. So it's save to say it won't happen. Unless... I don't wish bad tings to happen to anyone, but if one day you are hunted by this gost... I'll keep hoping (knowing you can handle it).

Both our energy can be better spend. I posted 15 other ideas, and you seem to like at least 4 of them. That might be a more constructive cooperation. Win some, lose some, and occasionally we all win.

I did my best to save those poor newbees from dealing with this if they need it. They tend to get themself in terrible messes. I think AristosQueue hinted at this. Perhaps the property should be created. Using it might create a mess, but if you have a mess it might be the only way out.

[wiebe@CARYA]

OK now we're talking about two different things.  Are you intending registering for mouse events on the subpanel reference? 

No. The VI inside the subpanel registers for pane mouse down.

What if the VI is removed from the subpanel?

I know for a fact that that does not happen. At least not in my design. I know because only the plug in will remove itself from the subpanel. Remember clones are not removed from memory when removed after they stopped?

What if it is inserted to a different one? 

That whould happen through user event, and that events will be handled after the pane mouse down event.

How do you keep the event refnum up to date?

That's not an issue. Am I right that this question does not make any send given the answers above?

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. 

Again, this will all happen in the same event pipeline, and therefore I know a window size change happening before the mouse down will be processed after the mouse down event.

Hard to belief, I'm sure. All windows in this app have a custom windows look. Even the borders need to look different. So all VI borders and title bars, etc. are removed (an empty square canvas remains), and they are replaced by my own border and title bar decorations. Sizing is done by overlaying a 99% transparent VI with the same dimensions as the real window. This VI is sizable. When it is resized, the master changes it's size though a user event, and that causes all subpanel plugins to get a pane resize event. A click and a resize always follow in the right order. Same goes for closing, and changing plug in.

I told you I take on the weirdest challanges. If I did not, I'd be making pilot plants and DAQ apps day in day out. When a customer wants to pay me for making the impossible, I grab the challenge with both hands.

Therefore the lag between generating the event and reaching the final translated coordinates is not foolproof.

I've not seen it fail jet. I think it is.

I do admit that this is a very specific situation.

To be honest (We're being blunt, right) the discussion is getting rather long-winded. 

[wiebe@CARYA]

I'll reply to this after the bar. It's better suited as ending.

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?

The coordinates are correct, in the sence that they provide the information I am interessed in. They just need to be converted.

in contrast, the device interface VI give the wrong information (the current mouse position not the clicked mouse position), but they are screen coordinates so would not need conversion.

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 am interested in the mouse coordinates of a mouse click. Not in the current mouse coordinates. I can see how this is confusing, i though the diffence was clear from the context of the remark. The device interface gives the mouse coordinates [of the current position] while I am interested in the [mouse coordinates of the] click position.

---

---

To be honest (We're being blunt, right) the discussion is getting rather long-winded. 

Don't hold back on by account. I have a think skin. I don't mind long winded discussions myself. Weekend started, I was longing for a beer since you mentioned it.

Even if I can convince you (which is unlikelly), the thread will have two kudo's at time of writing. So it's save to say it won't happen. Unless... I don't wish bad tings to happen to anyone, but if one day you are hunted by this gost... I'll keep hoping (knowing you can handle it).

Both our energy can be better spend. I posted 15 other ideas, and you seem to like at least 4 of them. That might be a more constructive cooperation. Win some, lose some, and occasionally we all win.

I did my best to save those poor newbees from dealing with this if they need it. They tend to get themself in terrible messes. I think AristosQueue hinted at this. Perhaps the property should be created. Using it might create a mess, but if you have a mess it might be the only way out.

[AristosQueue (NI)]

> >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?

There are ideas that we close for the obvious reasons: logically impossible, already in LV, already rejected, duplicate idea, that sort of thing. But when I or one of the others in R&D see an idea that we think should be closed as just a bad idea, we put it on a list to discuss the next time we review.

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

It depends.

> 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).

Merely because we have existing hacks (shared variables, aka, universal variables, which are even broader than global variables) does not justify more. I've tried to explain why it's a bad idea, but if you've never seen UI architectures go off the rails when children go looking for parents, you may not recognize just how messy it can get. It is my experience that it is a sufficiently bad idea that I wouldn't willingly add it to the toolbox any more than I would offer a Jedi a double-ended lightsaber. Seriously. Pick up a quarter staff and try to fight with out it touching you. I don't care how much Force you have, you'll be forever off balance if you have to push both ends of the stick away from your body. But it looks soooo cool on screen. Same with this property.

[wiebe@CARYA]

Merely because we have existing hacks (shared variables, aka, universal variables, which are even broader than global variables) does not justify more.

No, but it does weaken the argument that adding one tiny property is evil. It's about balance:

Me: can be usefull, and relativelly harmless

You: is not usefull, and bad

I've tried to explain why it's a bad idea, but if you've never seen UI architectures go off the rails when children go looking for parents, you may not recognize just how messy it can get. It is my experience that it is a sufficiently bad idea that I wouldn't willingly add it to the toolbox any more than I would offer a Jedi a double-ended lightsaber. Seriously. Pick up a quarter staff and try to fight with out it touching you. I don't care how much Force you have, you'll be forever off balance if you have to push both ends of the stick away from your body. But it looks soooo cool on screen. Same with this property.

you are only right if you make the premisis that you LabVIEW should protect the programmer.

This is for instance how C++ and LAVA are very different. C++ wants to make everything possible, JAVA wants to make sure no violation can happen. I'd like LabVIEW to be more like C++, I think you're leaning to JAVA.

If I where a Jedi (I'm following night classes), I would like a double-ended lightsaber. I will only enable one end, but if two enamies attack me from the front, I'd put it in front of me and put both ends on. I'd like the option.

The way I see it:

No newbee will ever use this to make an architecture, because they're not that experienced

No expert will ever use this to make an architecture, because they're are that experienced.

But an expert might need it in some rare occasion, and sigh: "oh, again one of those LabVIEW idiosyncracy".

On Lava, Daklo says:"Although I love developing in LV I'm beginning to see the day when I'll "outgrow" (for lack of a better term) it on the distant horizon.". I can relate.

[Intaris]

Daklo says:"Although I love developing in LV I'm beginning to see the day when I'll "outgrow" (for lack of a better term) it on the distant horizon.". I can relate.

I've had that sentiment on several occasions.

I can relate also.

Spoiler

Even though I think it may have been Daklu, not Daklo.

[wiebe@CARYA]

Oops his name is Daklu. Can't edit it anymore. Sorry Daklu.

[AristosQueue (NI)]

> you are only right if you make the premisis that

> you LabVIEW should protect the programmer.

Let me go turn off strong type checking and allow raw pointers to wire data spaces. We only have those things "to protect the programmer".

Or, to put it another way -- yes, my job is to provide *appropriate* protections for a programmer working in the LabVIEW environment. Power is often increased when you can depend upon a feature working in a particular way. Providing exceptions weakens the ability to build larger architectures.

Encapsulation and inheritance requirements are all about one programmer imposing limits on the next one in line. This particular idea fails that balance in my opinion.

[wiebe@CARYA]

>Power is often increased when you can depend upon a feature working in a particular way. Providing exceptions weakens the ability to build larger architectures.

I don't see how this feature will ever not work in the expected way.

Anyway, in Phanton Menace Darth Maul has a double sided lightsaber. Was that the point? That he has a double ended lightsaber and that he is evil?

[AristosQueue (NI)]

> Was that the point?

Yes, Darth Maul was the point.  http://starwars.wikia.com/wiki/Double-bladed_lightsaber

"Special training was required to wield the weapon effectively, with those attempting to use it without such discipline likely to bisect or impale themselves."

[Darren]

Any idea that has received less than 2 kudos within 2 years after posting will be automatically declined. 

[BertMcMahan]

I know this thread is old but I came across it today because my fun new popup-menu QControl plugin stopped working when I started using it inside a subpanel.

Wiebe, it's been a few years since you've looked into this. Have you settled on a good way to do this, other than the "get mouse current position" function calls? At least as of LV2018, the Convert Panel to Screen Coordinates function just plain doesn't work when it's called within a subpanel.