Repurposing the parts of a VI when making a plug-in system: Is this a hack or good practice?

[Aristos Queue]

The tl;dr is the two lines in bold face.

 

I'm building a plug-in system. This is a project on my own, not a work assignment, although I will admit that this is one of those side-projects for which I have greater plans, should it pan out.

 

Plug-in authors write a single VI that goes in the plug-in directory. When the application runs, these VIs are scanned to provide the functionality options.

 

The user of the application will be presented with a selection list to choose the operation he/she wants. That list is a list of all the plug-ins. I don't want to just show a list of VI names, primarily because I may be localizing these VIs for different human languages. I also want to be able to have a context-help-like system for each menu entry so users know what they are picking.

 

Here's my question: If each plug-in is defined by a top-level VI, is it good practice to use the VI Title and the VI Description as the place for the plug-in author to define the menu text and the help text? I'm never going to show the front panels of these VIs, so I don't have to worry about a VI having a title that only makes sense in the context of a menu or something like that. These VIs won't be in anyone's palettes nor appearing on block diagrams, so the usual venues for the VI Description do not get used. So it is totally *technically* feasible to reuse these fields.

 

The idea appeals to me most especially because the Title and Description are fields of a VI that are exported by Export Strings, making them easy to localize. If I use something like VI Tags, I have to build a custom localization tool. If I put controls on the panel, those become part of the compiled code of the VIs. Both the tags and the controls require a lot more VI Server code to extract the text from the VIs, and require plug-in authors to follow some sort of naming convention for the tag or control. I think I can even get the title/descriptions without actually loading the VIs (haven't checked on that).

 

The only other option I can think of is that the plug-in actually is a text file of some sort that lists the VI and the menu text and the menu description. Again, requires a custom localization procedure. I have a general phobia of custom text files... they tend to become crufty as new features get requested over time. I've built many of them in my personal code, but the only one that I've inflicted on users in my professional career at NI is the *-errors.txt files for defining error codes. That one is full of rookie mistakes in file design, but even if those were cleaned up, it wouldn't have helped the file's development over time. Over the last 13 years, we've started hiding several new things in parts of those files that previously were comment blocks. But, hey, it worked for HTML, so it must be a good idea, right? Right. But that's what happens with custom text formats. (This ties in to another "is it a hack?" question: "Should you always include a gratuitous string field in any significant API in version 1 so you have a place in version 2 to stick all the fields you never thought of in version 1 without breaking backward compatibility?" But that's a question for another thread.)

 

Using the Title and Description feels like a solution that is right, well, and good. If you know of any reasons to declare it wrong, bad, or evil, please share.

[ShaunR]

I don't see any problem with it. After all. The VI description is the help (in the IDE) and the VI name is by default the same as the on-disk name which only palette writers really care about.

I would argue that exporting strings is no reason to do anything though, since it is the worst translation tool ever, (Hence the reason I wrote Passa Mak many moons ago).

[Mellroth]

...Using the Title and Description feels like a solution that is right, well, and good. If you know of any reasons to declare it wrong, bad, or evil, please share.

 

The only reason I can think of is that if you have a plug-in that can be used multiple times in your application, the Title and Description would be shared between menu entries. With a text based plugin, menu items with different names can use the same plug-in code.

 

/J

[mje]

I don't see any technical barrier to doing this.

Stylistically I'd argue to look at a different way. I have a general aversion to using features/constructs/widgets clearly outside of their intended purpose. For me VI descriptions are the singular most important piece of documentation a VI can have that is guaranteed to always come along for the ride. Using it to provide end user visible text is not at all what I think any LabVIEW programmer would expect.

[Tim_S]

I implemented something like you're describing back before objects. It worked, but it was a lot of work to document and remember what was needed for everything to show up properly. I've switched to objects for plugins; the objects have properties for name, description, etc., which could be set up for localization.

[Aristos Queue]

mje: Since this is a scripting tool, the menu items are functional choices, so I think this meets even your objection... the VI Description is the description of what it does.

[Ton Plomp]

Yes, it's a valid option (IMHO), for the plugins in the Code Capture Tool we have used this method, and we even use the icon!

Only downside is that you need to load the VI into memory to get this info. What surprises me is that you didn't choose an OO implementation with specific methods.

 

Ton

[Aristos Queue]

Ton: No, you don't need to load the VIs... there are methods on App references to get info about VIs without loading them. Take a look at the invoke node.

 

And I am using an OO approach ... each of those VIs maps to a class, and the class maps back to the VI, but the VI is not a member of the class. This is giving me some interesting freedoms for componentization. Not an option I would pick for most projects, but one I believe to be the right choice in this case. If it all works out as planned, I'll have more to talk about.

[Daklu]

mje: Since this is a scripting tool, the menu items are functional choices, so I think this meets even your objection... the VI Description is the description of what it does.

 

I tend to treat the vi description as notes for other developers who are using the vis on their own block diagrams.  The connection you're making feels like a stretch.  That said, I don't have any strong objections to your proposal.  A vi is just a generic container with some built-in features.  How you choose to use those features is up to you.

[JackDunaway]

Here's my question: If each plug-in is defined by a top-level VI, is it good practice to use the VI Title and the VI Description as the place for the plug-in author to define the menu text and the help text?

 

I'm currently using precisely this technique (private App method and all) for a commercial product. It has worked great in practice for end-user plugin devs.

 

The key is approachability for plug-in developers. A "safer" but significantly less approachable alternative is to write this metadata as Tags to the VI. (I investigated and rejected using Tags for this task; it's conceptually far easier to explain Title/Description editing, and does not require custom tooling/APIs to edit data that should be readily editable by devs).

 

Lowering barriers for plug-in development has far more value than eschewing "the dirty feeling you get from overloading the meaning of fields". Go for it.