New palette options: 'Open VI' and 'Run VI'

[SteenSchmidt]

Hi

Currently on a functions palette item (when you edit the palettes) you have the option of placing the VI contents as an alternative to the default behavior of placing the VI itself on the block diagram:

I suggest two additional options in this menu: 'Open VI' and 'Run VI'.

Two such options will enable us to bundle help-VIs, scripting VIs and examples directly in a sub-palette of toolsets, instead of going the long almost impossible way of building bin3 files for the Example Finder.

One of many current use cases we have at GPower is the ExpressionTester in our Expression Parser toolset:

The ExpressionTester is a utility, a small application actually, that lets the user investigate different mathematical string expressions before committing them to code, and it has no use as a subVI. We feel it has the highest chance of user discovery when positioned just with the toolset functional VIs (i.e. in the palette), instead of being buried either on disk available through a link in the detailed help file, or in a Tools menu item. But to use it from the palette today, the user has to drop it on a block daigram, open the subVI and run it. And then remember to delete it again from the block diagram, preferably with CTRL+Z to avoid contaminating the undo-stack. If we could mark that palette item as 'Run VI' then clicking it would just start the ExpressionTester utility.

Perhaps palette items configured to being opened/run/content-dropped instead of the default action should have some sort of indication on it, that clicking it executes a non-default behavior?

Cheers,

Steen

[parthabe]

One suggestion to reduce one click...

Set your Expression Tester Utility with the 'Run when opened' option under the 'Execution' Category in VI Properties.

[SteenSchmidt]

'Run when opened';

Yes, in this specific case it could save a click, but it still remains that it's an awkward solution having to drop it into a BD where you have no plans of using it. And the 'Run when opened' setting is a pain during development and maintenance of the VI.

/Steen

[Thoric]

I support this idea, it's great. In PTP Sequencer I have three example VIs, and I do everything I can to point developers towards the Example Finder and hope that they bother to look. If my examples were right there, in a sibling functions sub-palette, and their front panels were opened when clicked instead of dropped onto the block diagram as a subVI, they would be much more likely to be discovered and studied by developers.

'Run when opened' is not a workaround to this idea, it just adds additional complexity. I despise this option because it can lead to suspicion and distrust. It's not hard to write a VI that sabotages your computer files. If set to Run when Opened and deceptively made available as a 'helpful example' then many unsuspecting developers who would end up in the ###. It only takes one malicious developer to create such a VI and post it somewhere public. In the modern security-conscious world I think this option ought to be protected (lie Macro-enable security in Excel) or simply removed.

[AristosQueue (NI)]

No.

Do you know how much yelling R&D would receive if the simple act of clicking on a VI in the palette started something running? Many users already yell at us for even having the option to "run when opened" on individual VIs. If they had to worry about it for things in the palettes? There would be pitchforks and torches headed for NI HQ. Thoric lays out all the reasons why "run when opened" is considered evil ... adding "run when opened" to the palettes --- even if it had some sort of highlighting halo around it -- would be just as bad.

Examples belong in the Example Finder. You can install your examples there just like NI does. If your users do not find them, then perhaps NI should do more to strengthen the awareness of the Example Finder overall, but they do not belong in the palettes. NI used to have examples in the palettes in some toolkits... it created as much confusion as it solved as people tried to figure out why the examples were part of the API. It also clogs up QuickDrop with useless entries.

[SteenSchmidt]

Stephen, I appreciate the security concern. I'm not thrilled myself about any way that would make arbitrary code run without the end-user's accept, but frankly that could be solved in a number of ways - for instance a confirmation the first time the user clicked on an item that was about to autorun. Such authentications (and ways to revoke them) are built into a number of existing applications; active content on web pages come to mind.

Depending on the implementation Quickdrop could easily be made to ignore these types of files - it ignores so many other things, XNodes for instance. Or perhaps QD would even be a better interface to get to examples and help than the Example Finder?

Examples (and detailed help, just as custom error lists) seem quite orphaned in LabVIEW. There isn't a consistent methodology about them. "You can install your examples there just like NI does", well that won't happen. I have been there and done that, and my time is simply too precious to fight that arcane way of deploying examples; Making multiple VI-packages, installing the toolset locally first without examples just to be able to build the example VIs. Then fire up the bin3 builder which is a really dense application. Then uninstall the toolset again and build a new VIP, this time including the newly built bin3 file (now we've used two build numbers). Then install the toolset again and test the examples. If the examples aren't perfect, then all over again... No, I won't do that ever again with the current tools. In some situations that workflow isn't even possible (licensed toolsets where you use up a key or activate a dongle for instance).

In my opinion examples and help would be much better off together with the toolsets themselves. If we have a tool that installs in a menu, wouldn't you expect a submenu that contains help, or perhaps a button directly accessible to the user (like the 'Merge VIs' tool, where there is a Help button right on the app front panel. That help content isn't stuffed away inside a global help-repository in LabVIEW or maybe even in the OS).

I totally agree that these aux features mustn't be confused with the core functionality of the toolset, but that could also be solved in a number of ways. We have already covered tools that install in a menu. For tools in a palette the palettes themselves could be redesigned a bit to accomodate this extra functionality;

Even some of the detailed help files of the built-in functions have links to their examples directly from the help file. Probably because it seems like a good place to locate them?

Cheers,

Steen

[AristosQueue (NI)]

Even when loaded from Example Finder, we do not mark examples we do not mark as "run when opened". So even if you decided to put them in the palettes, I still wouldn't support making them run when opened.

[SteenSchmidt]

I agree that Run when opened can be a problem. I didn't think much about that feature before posting this idea, since I simply do not use it (I see no value in it, and I agree completely with you and Richard in regards to the security issues - 'Run when opened' is grief laced with pain). The discussion about it is sound though, so I welcome it.

The issue I'm trying to process here is two-fold;

1) Example Finder is a major pain to deploy to. To the point that I simply refuse to do it.

2) Investigating ways to maintain a closer link between a toolset and its help and examples. I think the palette is a good place for those things, but a discussion about it is good. Debating usually means I end up somewhere else than where I started.

On a parallel:

It occurs to me that the whole idea about QD plugins is exactly 'run when opened' of each and every script in there. I doubt the average LV user inspects all the scripts in QD before using them. QuickDrop filled this void where we didn't have any place to put automation functionality into LabVIEW. We do now, but that seems quite well endorsed by NI? I'm not advocating opening up new avenues for automated havoc and putting security to a side, I'm just making an observation about QD plugins here.

/Steen

[AristosQueue (NI)]

Ideas to make Example Finder more amenable to access would be fine in my book.

There is a difference between installing code that you expect to run -- i.e. placing new plugins into QD's directory -- and double clicking on a file because you want to open and inspect it.

The reason that "run when open" even exists is because many users historically have wanted to have a full version of LV on a machine and have operators double click on a file and run it. They didn't have AppBuilder to build EXEs (many users still exist in this category, particularly within universities).

For myself, I don't click on VIs to open them in LabVIEW. How would that ever be meaningful? Even if I only have one LV version on a machine (rare, but I do have some machines that are isolated like that), how would the VI know which project to open them into? It wouldn't. But I know many people like working without a project (I honestly do not know how you get work done, but I've watched over your shoulders with a certain amount of amazement), and for them, they can get away with double-clicking to open a VI.

[SteenSchmidt]

>> There is a difference between installing code that you expect to run -- i.e. placing new plugins into

>> QD's directory -- and double clicking on a file because you want to open and inspect it.

Yes, but we were discussing the evil intent of the programmer of the code, and in that light it's equivalent. If an item in a palette was sufficiently marked as an "action item" you would expect it to do something other than merely end up on your mouse pointer to drop in your BD.

I understand the reasons for 'Run when opened', but there could still be a safety guard (that you had to acknowledge the first run of anything marked as such) which would also put a safety on such palette items.

I often double-click on a VI on disk to open it in LabVIEW - if there is some piece of code I need to inspect and want to do it much faster than to open up an entire project (can take minutes or half hours in some cases), or if I need to do a small change and be done with it (this is rarer, as the context is usually important here). It depends on if my task is to change one thing in one place, or if it is to change several things or a shared setting or component - in the latter case I of course open up the project, class, lib or whatever and start from there.

[AristosQueue (NI)]

You have to have trust in all your sources of executables if you're going to install them. Opening a source file is not expected to be an executable. That's what makes "run when open" different. If it had a unique file extension, then it would be different.