New override code instead of ancestor subVI

[jacemdom]

[crelf]

yes Yes YES ! ! ! !

[crelf]

Note: I usually don't use this function - I use the "Clone VI" in the Endevo GDS ( http://www.flander.net/English/Endevo/Products/GoopDevSuite/tabid/8080/language/en-US/Default.aspx )

[AristosQueue (NI)]

a) What would be the behavior if the parent imlementation uses private subVIs or accesses private data since these cannot appear on the diagram of the child?

b) Obviously it wouldn't work if the block diagram of the parent is password protected. Otherwise anyone would have a cheap way to view diagrams they don't have the password for.

c) Why do you want this? I'm really curious since I can't think of any time when it would have been desirable in any language I've worked in. Generally, if the diagram of the parent is NOT password protected then it is better form to do "create subVI" in the parent for the part you want to override and make that new subVI be dynamic dispatch. 

[Intaris]

AQ, speaking for myself it's goof for cases where Inheritance is used to create many slightly different versions of a single operation.  Especially in combination with a base class which is being used as an Abstract class with a basic implementation of what is to be performed it could save a lot of time getting the different flavours up and running if this option were available.

I personally think it would be great.  I also think it would be great to be able to browse fo the VI to copy the BD from instead of simple from the Parent.  Sibling copy could be very useful also.

[AristosQueue (NI)]

> it's goof for cases

Typo, right? I'm guessing you meant "good".

> AQ, speaking for myself it's good for cases where Inheritance is used

> to create many slightly different versions of a single operation. 

Replicated code is never good. If you have slightly different versions, why not have a single copy in the parent of the parts of the code that are identical and only override the part that is actually different, the part that you don't copy at all? That's what I'm missing. 

>  Sibling copy could be very useful also.

Same argument as copying parent applies here. 

> browse fo the VI to copy the BD from

Would you require that the selected VI be dynamic dispatch so that terminals can be replaced? If not, then just use Save As:Copy as it exists today. 

[Intaris]

AQ,

yes goof was a freudian slip... 🙂

Some code needs to be copied sometimes, even if it's only a wired case structure or something relatively simple like that.  Taking the idea of avoiding copying code is all good but there are some places where it's just necessary (Especially when dealing with hardware -  there are always exceptions to any rule - My crrent USB project s a shining example).  Some devices just don't behave correctly and it's exactly THESE cases which make it incredibly difficult sometimes to have a code one and inherit principle in reality.

But hey, that's just my 2c.

[AristosQueue (NI)]

Ok, I can agree with the statement "there are some times when you just have to copy code." But those should be rare and not desired. Why would we put a checkbox into the dialog for what should be a rare situtaion, thereby encouraging its use? Why spend time making easy an option that mostly should not be used? Save As:Copy is pretty straight forward, and then you just do popup>>Replace on the dynamic input/output to fix up the VI.

[Intaris]

Does giving the option encourage code copying?  I think those who know LVOOP know what to do.....

PS I personally find the "Replace on the dynamic input/output" really annoying (should probably write myself a tool for that....)

[AristosQueue (NI)]

> Does giving the option encourage code copying?  I think those who know LVOOP know what to do.....

Yes, it does encourage it. And, no, most of those who are (and will be) using LVOOP don't know what to do. 

LabVIEW is a programming language for non-programmers. Our goal is to make it so that those with no training with programming can program the computer successfully. Much of the time, this means designing the user interface such that users luck into good decisions. We spend a lot of time considering whether to promote options or hide them based not only on what would be convenient for those who would use the option but also on whether that option might be too visible for those who shouldn't be using the option. 

Take gobal VIs for example. This is not a scientifically rigorous example, but annecdotaly it demonstrates my point. Currently it's a bit tricky to figure out where in the UI you have to go to create a new global VI. I gave one of my friends, who was unfamiliar with LV but knew a smattering of other programming, a modified version of LV where "new >> global VI" was more obvious. And, as I had predicted, after working with it for a couple days, he produced a sample app, one that had globals everywhere instead of dataflow. The program worked, but it was dog slow.

I've never repeated that experiement with a larger group, but my understanding is that LV saw this sort of thing all the time in its early days. As a result, we have a slightly different behavior than other apps. In some apps, if you have an option that few people will use but that you can put into the UI without disturbing the main use cases, you go ahead and do it to be easy for the few. But in LV, we tend to bury those options so they aren't even easy to get at for the few because it changes the learning path that most of our users go through. 

When we developeed LV Express in LV 7.0, we spent a year attempting to have LabVIEW present two different user interfaces for two different groups of users. In one, the palettes would be the Express palettes. In the other, the palettes would be the full programming palettes. There were a host of other differences as well. The experiment was a terrible failure. When a user launched LabVIEW for the first time, we presented a dialog asking them a question. The question was intended to decide which of the two interfaces we should present. We tried

-- new user vs experienced user (but some new users should have the programmer interface)

-- small scale app development vs large scale app development (scale of app has no meaning for the UI you want for developing the app)

-- basic user vs advanced user (no one ever picked basic user)

-- developer vs programmer (people decided this almost randomly it seemed)

and a bunch of others. Those are just the ones I recall. We decided that LV's default interface could really only serve one populace, and we felt that our advanced users could figure out how to change their palettes, update their Tools>>Options, etc. And that's guided LV UI development ever since. 

[jacemdom]

"What would be the behavior if the parent imlementation uses private subVIs or accesses private data since these cannot appear on the diagram of the child?"

Greyed out

"Obviously it wouldn't work if the block diagram of the parent is password protected. Otherwise anyone would have a cheap way to view diagrams they don't have the password for."

Greyed out

"Why do you want this?"

Probabaly for the same primary reasons as LVOOP...efficiency...some will argue code quality...but then quality ends up in efficiency...so as code reuse...

"Would you require that the selected VI be dynamic dispatch so that terminals can be replaced?"

Yes

"Why would we put a checkbox into the dialog for what should be a rare situtaion, thereby encouraging its use?"

Because the functionnality already exists when you add inlineSubVIEnabled=TRUE in the LV ini file and then right-click on the ancestor VI. So it should not be a big effort to put a check box to do it automatically.

As for encouraging its use...same argument as for the sequence structure...

"Why spend time making easy an option that mostly should not be used?"

Because the functionnality already exists...So it should not be a big effort...

"Save As:Copy is pretty straight forward, and then you just do popup>>Replace on the dynamic input/output to fix up the VI."

efficiency...do more with less clicks...

It is more than just the terminals, you have to also have to save it in the rigth directory and add it to the class...

Oh! my god some will say! What a lot of work!

Don't forget that it is NI that made us that lazy with LabVIEW!!! think of all the coders that still struggle with C or VB...those are the real warriors with lightning speed typing fingers...

me i am just a lazy clicking joe that want's to click a bit less everyday, a couple of clicks here...some right-clicks there ! 🙂

I was out of the LabVIEW life for quite some time and when i returned to it in the 2009 version and decided to give LVOOP a go a couple of days ago...i was quite impressed that NI as achieved to speed up the development process even further and even made LVOOP attractive to me who comes a long long way from AnotherVIEW to LVOOP...

my "coup de coeur" goes to the icon editor...when used with properly configured class or libraries...

create new VI...double-click icon...write text...click ok...done! wow!