Providing a template for overrides

[mje]

The default implementation of an override VI is to simply wire up all the terminals to a call to the parent VI.

I have a framework class where a method almost always has to be overridden, and I find myself duplicating code every time I create an override VI for a new class. Let me clarify, the code of each VI will ultimately be different, but they all share a common starting code, not unlike whenever you select a new Producer/Consumer VI for example, the familiar loop structures are always laid out. So I think this is a different issue than what Jim posted about earlier today.

I'd like to define a template such that whenever a method is overridden, the new override has a starting bit of code in it beyond what currently is defaulted to. Defining the parent dynamic VI sa a VIT doesn't seem to do the trick. Is there a way to do this?

[Justin Goeres]

I've never done the specific thing you're talking about, but if it's possible it will probably involve venturing into

<labview>\resource\Framework\Providers\LVClassLibrary

That directory contains the VIs that LabVIEW uses to (among other things) create accessor and override methods. If you poke around in there you will find .vit's for read & write accessor methods that you could probably replace with your own versions if you're into that.

What you're talking about, though, is replacing the template for override VIs. I don't see a .vit anywhere for those, so it's apparently not as straightforward as the accessor methods. That having been said, there is a VI called CLSUIP_CreateOverride.vi that is probably implicated in the process. It's all very black-box because everything is password protected, but if you felt really really brave you might be able to work out how to bend things to your will.

And if you figure it out, please tell the rest of us .

[Aristos Queue]

QUOTE (MJE @ Feb 18 2009, 01:15 PM)

Defining the parent dynamic VI sa a VIT doesn't seem to do the trick. Is there a way to do this?

No, there's no way to do this. When LV is asked to create a new Override VI, we *ALREADY* start with the parent VI as the template VI. This gets all of the connector pane, VI properties, and front panel. Then the diagram is wiped except for the FP Terms, a call parent node is dropped, the terms are wired up, and the controls of parent type on the FP are substituted for child type controls, including updating the labels if the parent label text includes the name of the parent. To do what you're asking would require amending that entire process.

HAVING SAID THAT...

If you have "a common starting point", that suggests you are overriding at too high a level. In other words, you currently have Parent:DoSomething.vi and you are overriding with Child:DoSomething.vi. What I'm suggesting is you consider taking the "variable" portion of Parent:DoSomething.vi and make that another subVI -- call it Parent:DoSomethingCore.vi -- and then override that core VI. Part of why we wipe the entire block diagram is that ideally the child doesn't have any code that is duplicated by the parent.

Would that work for you?

[mje]

Ah, that's interesting to know how it's done.

The "common starting point" really must be replicated. It's a set of two nested case structures, shown below.

It's really just a tiny thing, but man, would it be nice to have any override already have that code in the diagram. Not only is it convenient, but it demonstrates the intended use of the method.

[Aristos Queue]

QUOTE (MJE @ Feb 18 2009, 09:40 PM)

The "common starting point" really must be replicated. It's a set of two nested case structures, shown below.

Ah. I see. Yes... I agree... something like this would be useful for you. Hm... well...

Attached VIs are saved in LV8.6...

Replace

<labview>\resource\Framework\Providers\LVClassLibrary\NewOverride\CLSUIP_CreateOverride.vi

with the new version here Download File:post-5877-1235021532.vi (BACKUP YOUR EXISTING VI FIRST!) and save the new "User Scripting For New Override.vi" Download File:post-5877-1235021543.vi in the same directory.

You now have a hook to write your own scripting code into the process. The new subVI gets invoked after all the other scripting is already complete, so you can delete what's there and start over or somehow adjust that diagram to suite your needs. I can't help more than that at this point.

[mje]

Wow, thanks for the replies...to be honest I never expected it would be doable.

Looks like I'm delving into unknown territory for me here, this might take some time. Thanks for the pointers all of you, and thanks a bunch for the VIs AQ. I'll have to look into scripting, it's been something I've been avoiding so far, but it ought to be fun!