Efficient way to create HAL child classes using object oriented

[ScottTron]

Howdy.  I'm working on creating a hardware abstraction layer in LabVIEW using object oriented programming.  Here is my situation that I am hoping to get some advice on...

I have a parent class that defines all the methods\public VIs for the hardware class.  Each VI has the inputs/outputs (controls/indicators) defined, but really has no source code.  The parent class is really just a definition for this case.  Then I create child classes for "Vendor 1", "Vendor 2", etc.  I'm trying to figure out the best way to create those child classes and have come up with two options so far.  Neither seem perfect. 

Option 1 - Create the child class, make it inherit from the parent class, then create "VI for overide" for all the VIs in the parent class.  This works becuase it copies over all the inputs and outputs for the child methods, but what I don't like is what it does with the block diagram.  It makes the VI so that it calls the parent method, which is exactly what I don't want to do.  So for every VI, I have to delete that, expand the diagram, and add in all the error/no error case structure.  This seems trivial, but if I have to do it 300 times, it gets tedious.  What I really want for the "VI for overide" is for the block diagram to look like the diagram if you do "new VI from dynamic dispatch template"  Is there any EASY way to automate this?  

Option 2 - Make a copy of the parent class and rename it to "Vendor 1 Class"  Make the vendor class inherit from the original.  Now I have all the block diagrams the way I want them.  The only problem I see here is that all my child classes will have the same exact wire colors and the class object control/indicator for each VI won't be named uniquely.  I haven't really tried this way yet, so I'm not sure if I will have other issues with this method.  

What does everybody else do?  Either of these?  Something else?  

Thanks! 

Scott

[nathand]

If you're willing to get into LabVIEW Scripting, you can modify the script that runs after creating a VI for override, as explained here: https://decibel.ni.com/content/thread/15278, so that it removes the elements you don't want.

[ScottTron]

I'm not completely opposed to doing some scripting.  If that seems to be the only solution, then I may take that route.  For anybody else reading this, the other post basically gives you the location of the VI to add the scription to:

From AristosQueue:

Find and edit the VI

     resource\Framework\Providers\LVClassLibrary\NewAccessors\OverrideRetooler\Custo m User Scripting For New Override VI.vi

That gets called at the end of scripting override VIs. You're free to add any code you want there to adjust the final results. The other scripter classes have similar VIs. Most of the scripting tools are password protected, but these are left deliberately not password protected by me to give you hooks into the process.