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.

[Intaris]

Wiebe: The more I read your posts, the more I disagree with them.

I had originally written a whole lot of text responding to your posts point by point but I don't think that's going to be very fruitful  Instead I cut my response down to the following two statements.

1. The crux of your problem is that you need to be able to expand the functionality of your system as a whole without updating your core code.  Your solution is VI Server.  Which doesn't do some things you want, or at least not HOW you want.  You COULD always get an application refnum, get any open VI FPs, isolate SubPanels on them and then read out the reference for the VI within and try to match it to your caller.  Sure it's long winded, but it'll do what you want won't it?
   
   
2. My solution? You need your master to accept LVOOP messages via User Event from your other processes.  This way the new methods are added as new message classes (part of the plug-in not your master) and you can do what you want.  Part of the object the message is actually called on contains a VI refnum for the master.  Then you can do with it what you like.  I still don't like the taste of it neccessarily but it's do-able.

When reading your posts I get the feeling that you promised too much too early without due thought and consideration and are now under time pressure to do the impossible.  I've been there, done that and the tone of your posts reminds me of that quite strongly.  Forgive me if I'm wrong.  But adding a method to LV (which would be present only in a future version) to do something which is perfectly viable today via other methods smacks of desperation.

[wiebe@CARYA]

Wiebe: The more I read your posts, the more I disagree with them.

It's mutual.

I had originally written a whole lot of text responding to your posts point by point but I don't think that's going to be very fruitful  Instead I cut my response down to the following two statements.

You are right, it's going nowhere...

1. The crux of your problem is that you need to be able to expand the functionality of your system as a whole without updating your core code.  Your solution is VI Server.  Which doesn't do some things you want, or at least not HOW you want.  You COULD always get an application refnum, get any open VI FPs, isolate SubPanels on them and then read out the reference for the VI within and try to match it to your caller.  Sure it's long winded, but it'll do what you want won't it?

So you actually prefer this over making a sub VI? That is the hole point. Every reference has a Owning VI property. Why? Because it could be usefull. Why is it sooo evil to get a reference to a subpanel?

1. My solution? You need your master to accept LVOOP messages via User Event from your other processes.  This way the new methods are added as new message classes (part of the plug-in not your master) and you can do what you want.  Part of the object the message is actually called on contains a VI refnum for the master.  Then you can do with it what you like. I still don't like the taste of it neccessarily but it's do-able.
   

I do not need the main VI to do something. Why on earth would I send messages to the master?

I need a subpanel reference to:

+ do some coordinate calculations

+ perhaps hide a button that is only needed if running outside a subpanel.

Simple stuff. If I needed a subpanel reference to, for instance, register events of it's containing VI, then sure, this isn't that neet.

Why do you resent simplicity?

Why not pass the subpanel ref to the Vi when I insert it, since a property is lacking?

When reading your posts I get the feeling that you promised too much too early without due thought and consideration and are now under time pressure to do the impossible.  I've been there, done that and the tone of your posts reminds me of that quite strongly. 

This is not a current problem. In fact it's no problem at all. I know how to solve it, and have solved it. It's the fact that I have to solve it that is frustrating. I'm a big boy, I've been around.

If I where under time pressure, the last thing I'd be doing is posting on a forum.

Forgive me if I'm wrong.

You are forgiven (and wrong). (I admit, not a very constructive remark. Appologies in advance)

But adding a method to LV (which would be present only in a future version) to do something which is perfectly viable today via other methods smacks of desperation.

That is just blunt. Really? So suggesting an easy way to avoid complicated constructions is an act of desperation because "it can be done another way"? Every idea posted here can be done another way or avoided alltogether. Let's not repost bugs either. They will be solved in later releases, and thus be useless now.

Last try:

With this property: 2 minutes work to make a VI.

Without it: user events, coupling, design changes, dependancies, SCC changes to unrelated code.

I give up...

[wiebe@CARYA]

Wiebe: The more I read your posts, the more I disagree with them.

It's mutual.

I had originally written a whole lot of text responding to your posts point by point but I don't think that's going to be very fruitful  Instead I cut my response down to the following two statements.

You are right, it's going nowhere...

1. The crux of your problem is that you need to be able to expand the functionality of your system as a whole without updating your core code.  Your solution is VI Server.  Which doesn't do some things you want, or at least not HOW you want.  You COULD always get an application refnum, get any open VI FPs, isolate SubPanels on them and then read out the reference for the VI within and try to match it to your caller.  Sure it's long winded, but it'll do what you want won't it?

So you actually prefer this over making a sub VI? That is the hole point. Every reference has a Owning VI property. Why? Because it could be usefull. Why is it sooo evil to get a reference to a subpanel?

1. My solution? You need your master to accept LVOOP messages via User Event from your other processes.  This way the new methods are added as new message classes (part of the plug-in not your master) and you can do what you want.  Part of the object the message is actually called on contains a VI refnum for the master.  Then you can do with it what you like. I still don't like the taste of it neccessarily but it's do-able.
   

I do not need the main VI to do something. Why on earth would I send messages to the master?

[wiebe@CARYA]

I need a subpanel reference to:

[wiebe@CARYA]

+ do some coordinate calculations

[wiebe@CARYA]

+ perhaps hide a button that is only needed if running outside a subpanel.

Simple stuff. If I needed a subpanel reference to, for instance, register events of it's containing VI, then sure, this isn't that neet.

Why do you resent simplicity?

Why not pass the subpanel ref to the Vi when I insert it, since a property is lacking?

When reading your posts I get the feeling that you promised too much too early without due thought and consideration and are now under time pressure to do the impossible.  I've been there, done that and the tone of your posts reminds me of that quite strongly. 

This is not a current problem. In fact it's no problem at all. I know how to solve it, and have solved it. It's the fact that I have to solve it that is frustrating. I'm a big boy, I've been around.

If I where under time pressure, the last thing I'd be doing is posting on a forum.

Forgive me if I'm wrong.

You are forgiven (and wrong). (I admit, not a very constructive remark. Appologies in advance)

But adding a method to LV (which would be present only in a future version) to do something which is perfectly viable today via other methods smacks of desperation.

That is just blunt. Really? So suggesting an easy way to avoid complicated constructions is an act of desperation because "it can be done another way"? Every idea posted here can be done another way or avoided alltogether. Let's not repost bugs either. They will be solved in later releases, and thus be useless now.

Last try:

With this property: 2 minutes work to make a VI.

Without it: user events, coupling, design changes, dependancies, SCC changes to unrelated code.

I give up...

[wiebe@CARYA]

Ok, I don't give up. The "reaching deadline" tone of my posts is there because I take this stuff serious. I think you do to.

I know all posters (incl. me) in this thread know what they are talking about, so hence the frustrated undertone.

So how come we are not coming together on this? I think this idea is valid because:

1) one sometimes need it.

2) it is possible to work around, but to me that is complicated.

Now some examples I've given for 1), leads to solutions where indeed the work aournd (architectual solutions, like uver events) would be preferable. Like the print panel example. When i need it, the situation is much more complicated. I have nested subpanels with reentrant mains, and modules might be started in subpanels or not. Still the example is not very convincing. By bad.

Now to make any change of convinsing you of the practical use of this, I first need to prove 1). From every argument I get against this, I get a feeling that you do not believe there are situations where you need it, and therefore the solutions are not convincing me. Now I think I'll take some time to make better examples to show 1). Then I think for those examples I can show how silly those workarounds sometimes are. Allow me some time...

I just hope after these past posts you did not get into block mode.

[AristosQueue (NI)]

> So you are explaining to me how easy this is to do in a LabVIEW

> program (I'm not convinced), and it turns out to be really hard implement do in LabVIEW.

Not hard. It would be easy. Just wrong. 🙂

[AristosQueue (NI)]

> I hope I'm not coming over too hard and agressive. I'm Dutch, and

> we tend to be blunt. The text medium makes it wurse.

Not a problem. Direct is fine, and I recognize the limits of the medium. 🙂

[AristosQueue (NI)]

What Intaris and I are saying is that even having a need for this feature is symptomatic of really bad code. The argument that "it can be done now in 2 minutes compared to 2 hours" simply doesn't hold water when compared against the 2 months of refactoring needed down the road because you took the 2 minute shortcut.

You mentioned the goal of a VI being encapsulated within itself. If it has any reference to the caller VI, it is no longer encapsulated. Whether you use a user event to push requests up or a VI reference to pull data down, there's coupling there. The use of an event to push requests up is the better solution every application similar to what you are describing that I have ever seen. Now, some of those applications have done it backwards, and not all of them have paid the price for it -- generally because they either didn't have a second version of that software or that particular piece of code never needed to be modified again. But the ones that didn't take time to do it right ended up paying the time in debugging effort, testing effort, bug escalation effort or refactoring effort.

Because this idea is not technically impossible, I'm not putting this idea on the list of ideas we should consider closing. After all, we implemented global VIs once upon a time because enough customers said that the savings from the hack was worth it. But I would be surprised if this gets enough kudos to overcome severe architecture reservations.

[Intaris]

Wiebe.  My "desparation" comment was made in the context of being under time pressure and I think you realise this also.  I've been there.  I know what it's like.  I've cursed many a LabVIEW idiosyncracy in my time.

I'm also not arguing that adding this property would achieve what you're trying to do.  Of course it would.  And it'd be quick to implement (your code, not the NI part).  I still think the addition of the property would be a mistake.  We're arguing on the level of "is that what we really want" and not the "wouldn't this trick solve my problem".  Technically you're correct in everything you've posted.  I just find the motivations a bit misguided.  But should we ever meet and I can buy you a beer, it's perhaps the kind of discussion best left for such a time because it's quite likely that we'll never end up in the same boat in this regard.

Oh, and of course you're not going to get blocked.  Just because we're of completely different opinions on things doesn't mean we can't talk about them. While I'm convinced I'm correct in what I'm posting, I'm always open to input and am generally interested in the information of those whose ideas are quite different to mine.  This helps me continuously re-think my position.  I never believe myself to be infallible.  A single example where I have to pause and go "Hmmm" could be enough to sway me.  It could be I've simply overlooked something.

Your posts are valuable to me BECAUSE you hold a very different opinion to me.  Hence the applicability to discussing it over a beer.

[wiebe@CARYA]

Your all awake now, and I had some thoughts about this at night. All night in fact. It's now 5 AM.

Intaris, I'm all up for beer. I guess we're one the same mindset. A good discusion for me means no hard feelings even if we disagree.

I did not mean you'd block me or my mails. I ment you're mind has been block for the idea that it just might be possible that there are good reasons for having this feature. No point in reasoning if there is 0% change of results.

[wiebe@CARYA]

Damn. I just typed my new motivation. Autentification got lost becuase it seems to time out. 1 hour wasted. It will have to wait.

[wiebe@CARYA]

Ok, new try... I actually spend 2 hours on the previous attempt. I'll make it more compact this time.

I'll try to sketch a senario. I'll number small parts for easier reference.

---

1)

my situation is we've been making (and have to support) 50 to 150 new applications per year. for some it's just too late to give them all a proper architecture. Some where made when parallel while loops where as state of the art at it could get. LV changed a lot since LV4.1.

---

2)

I work with libraries (and classes since a year or so). Not .lvlib per see, but just directories where usefull stuff is stored. One of them is filled with usefull VI server stuff.

---

3)

Now when a user clicks and I need screen coordinates of the click (to create a popup there), it's convenient to make a VI for it.

---

4)

the VI takes a (pane and\or control or generic) ref, and it's coordinates returned by click (or move) events. It returns the click's screen coordinates.

Simple enough:

CvtPaneToPanelCoords

CvtPanelToScreenCoords

---

5)

Start using the VI... Turns out it does not work in subpanels

Below average LV programmers might give up at this point.

sidenote)

---

(Confusion start here: It works when the VI is runned! I've tested it!

Then frustration starts...

It seems like a bug in CvtPanelToScreenCoords to me:

"It converts front panel coordinates to screen coordinates" (context help).

No it does not. Change it to:

"It converts front panel coordinates to screen coordinates except when in the VI is in a subpanel, then it's useless. To make it work you need to use the subpanel VI's panel reference! But you can't get it... Good luck!".)

---

6)
We have a local issue, but to solve it we global context info.

---

7)
There is no easy, elegant, solution. Jet the problem is so simple.

Simple problems should have simple solutions.

Complex problems should be solvable.

---

😎

The VI Server solution will not work.

The master VI could be a clone (if you need multiple instances). We can't (as far as I know) get clone refs with application properties.

---

9)

sadly, no simple subVI solution.

No matter what solution (buffers, passing control refs, user event), we need to add code when the subpanel is filled, and code where we need to coordinates.

---

10)

using user events in this context seem extreemly complicated to me.

---

11)

in existing frameworks, the framework has to be changed when a plug in needs this. Yes, ideally this whould have been identified in design stage. But if you make beatifull software, requirements tend to grow (give them a finger, they'll take the whole hand). That is OK in general, scope changes means making money. But the costs need to match the expectations.

---

12)

I'll look for other reasons why having a subpanel ref is usefull.

I still feel that a subpanel VI should be able to have different behaviour\appearance between in and out of subpanel.