Use of MUST OVERRIDE

[CoastalMaineBird]

LV2013

I have a very simple class method, shown here in the parent class:

I want my users to override this method, so I set MUST OVERRIDE in the ITEM SETTINGS for this method.  Great.

All the child objects are broken, until I add such an override. Great.

But when I CREATE VI FOR OVERRIDE, the created vi does nothing except call the parent.

What I want is for the created child to have a diagram just like the parent above, where you "fill in the form" and save it.

Any way to do that?

[Kyle97330]

The way that I would do this would be to put all of the instructions on the front panel, not the block diagram.

One of the instructions would be to go into the block diagram and delete the "call parent" node and wire straight across instead.

Then, in the actual parent's block diagram, have it pass out an error every time telling them that if they see the error, they didn't follow the instructions to delete the call parent node.

[CoastalMaineBird]

The way that I would do this would be to put all of the instructions on the front panel, not the block diagram.

One of the instructions would be to go into the block diagram and delete the "call parent" node and wire straight across instead.

Yeah, there's merit in that, if I can't find the FORCE CHILD TO BE JUST LIKE THIS setting for the parent method.

I was hoping to avoid dealing with the front panel at all.

Thanks.

[Kyle97330]

Your other option is much more involved.  You can modify this VI:

<LabVIEW root dir>\resource\Framework\Providers\LVClassLibrary\NewAccessors\OverrideRetooler\Custom User Scripting For New Override VI.vi

Note that changes to this VI would affect every "New.. --> VI for override" that was performed, so not only do you have to add scripting to delete the call parent node and duplicate the parent's block diagram instead, you also have to filter it to only do it for certain classes/VIs.

However, as it looks like you're trying to make a distribution package that you can send to other programmers, you also need to realize that you'd be modifying their LV install instead of just dropping a library in a directory somewhere.

[CoastalMaineBird]

Yeah, I'm trying to make things simple for a less-skilled programmer to do.  I don't want to modify their LV install.

[JÞB]

Steve, you are hitting near and dear to my heart!  Trust me! TS9446 at NI Week 2016 plans to address this exact type of use case!

First option- use for the wole child class:  Create a Project Template for your new MyChildOfClass_xyz.  Iv'e never tried this with specific inheratance but it will probably work. (Those NI R&D guys must have thought about it while launching the AF.) MyProject Templates haven't gotten the user traction they deserve and need a solid developer to get the template "right" but are incredably powerful if ,you can get the users to use them.  Documentation of the template seems to be a key factor

Second Option- use for the specific child class member: Create a VI Template, *.vit, and stick it into <...>Frameworks\Design patterns and teach the users to use File>>New... to create a "New VI for Overriding Method_abc."  This seem to be very approachable by less experienced developers since a picture and some basic documentation is displayed in the side-bar of the File>>New... dialog window when the source vit is selected

Third Option- and this violates your desire to not want to mess with the client install.  Create a package with VIPM and a TK adding the Framework additions Kyle suggested based on LabVIEW application instance context.  You probably won't like that option but, it is possible.  I added it for completeness.  Messing with "Frameworks" is not for the feint of heart- you WILL be messing with your own LabVIEW install in the process of developing the framework hooks. (Read in the style of the Mythbusters famous quote "Do not try this at home-We are proffesionals)  You'll need a good reversion plan if you mess up during development.  

[CoastalMaineBird]

Thanks Jeff.  

I like option #2.

I've used VITs, but never connected them up to be available in the menu system.  Will have to look into how to do that.

To be useful, I need it to create a VI as a method of the particular class they are creating.

I don't quite see how to do that with a regular VIT, but I haven't put much thought into it.

I'll look into your ideas and see what comes out.

Thanks again.

[JÞB]

a *.vit that is placed in
C:\Program Files\National Instruments\LabVIEW 2013\templates\

It then acts like any other template you have access to from File>>New...  I'd show a png but, I'm installing NI Device Drivers Feb 2016 at the moment and its taking forever with the web-based installer  

[crossrulz]

---

@JÞB wrote:

Second Option- use for the specific child class member: Create a VI Template, *.vit, and stick it into <...>Frameworks\Design patterns and teach the users to use File>>New... to create a "New VI for Overriding Method_abc."  This seem to be very approachable by less experienced developers since a picture and some basic documentation is displayed in the side-bar of the File>>New... dialog window when the source vit is selected 

---

We will call this Option 2b.  Make a VI Template, but have it in the project.  From the project, you can right-click on the VIT and "Create New From Template".

[JÞB]

---

@crossrulz wrote:

---

@JÞB wrote:

Second Option- use for the specific child class member: Create a VI Template, *.vit, and stick it into <...>Frameworks\Design patterns and teach the users to use File>>New... to create a "New VI for Overriding Method_abc."  This seem to be very approachable by less experienced developers since a picture and some basic documentation is displayed in the side-bar of the File>>New... dialog window when the source vit is selected 

---

We will call this Option 2b.  Make a VI Template, but have it in the project.  From the project, you can right-click on the VIT and "Create New From Template".

---

You know what?  That may be a better idea.  It would handle the inheratance properties better since the vit in in the right context.