LabVIEW Idea Exchange

When creating VIs in a class that are meant to be overridden, it would be nice to have a template VI that will be used as the template. The easiest way I though of to accomplish this is to create an Override template that has the same name as the VI but with an extension like .OVIT (Override VI Template). 

An new item can be added to the context menu when right-clicking on the class to Create New Template for Override VI, which will give you basically the same format as a new vi from dynamic dispatch template, but will include the call parent VI followed by an error case structure.

This will allow an architect to create a template for coders to use and place any useful information on the Front Panel or Block Diagram. When the override vi script runs to create the new override VI from MyOverride.vi, it can search for MyOverride.ovit and if found replace the base class' type with the child class' type. Otherwise you get the default VI which has the call parent method.

I know this idea has been pass around before, but I thought I would respire it.

My goal is to allow architects to give more meaning full information to other developers and more complete starting points for overridden class VIs.

Issues that can arise

What if the VI is renamed? Then the maintainer of the class will need to also rename the template VI, but it would be nice if LabVIEW did this automatically.

What if the VI is removed from the project? The OVIT would also be removed.

What if the OVIT is broken, ie. won't execute? Like all class VIs, it should not be broken, the template should contain working code or disable parts that need to be implemented. It would be nicer if the OVITs were ignored for borken code and not allowed to be place on the block diagram for execution.

In the new controls of LV2011 are added the icons, but this icons don't are escalables. the ideal behavior that would be escalables, in the same proportion of the control (ideal selectable).

And to customize this icon, would be ideal to load it, a property directly wiht a selection of a graphic file, not "advanced\customize" and edit the control, and save it wiht a new name.

now

When you resize a String at runtime (for instance by resizing a panel and having set the string to scale with the panel), the scrollbar will snap back to the top of the string.

This is NOT the expected behavior.

I'd personally flag this as a bug.

Graphical Illustration.

Before (notice the position of the scrollbar and the text next to it):

After resizing the Window (objects are set to scale with the Panel):

Note that I am not saying that the workaround is difficult, but extrapolate to an interface with MANY strings (try an array of strings for kicks) and you start seeing a nasty headache raising its ugly head.

Ok this idea would be trivial for NI to include in 2011.Heck I could do it.

The idea is simply to include the JKI state machine in File/New/Design Patterns. It is BSD code and I am sure that JKI wouldn't mind anyway.

I must admit that I have an ulterior motive. If this were included in the NI distributed templates then I could use the JKI state machine for my CLD exam. And so could you!

Now let the kudos start rolling in so NI will take notice.

It would be nice to have a run button at the project level. Which VI to run could be selected in the project properties. 

I find that I often need to go looking for the top VI in projects. This is more true with actor framework based projects, since the launcher / splash screen will be closed after the software is run each time.

The icon for the VI in the project tree could be altered to denote top level VI or the VI that will be executed from the project run button.