Don't mislead users about unsupported functions in Real-Time VIs

[JKSH]

I posted this on the Idea Exchange 2 years ago, but it was declined due to the lack of kudos: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Don-t-mislead-users-about-unsupported-functions-in-Rea...

I'm posting it here again, to see what others think about this:

Issues

LabVIEW allowed me to place the Get Process List VI from the DSC module on an RT VI (it shouldn't). When I tried to deploy the VI, I was given a misleading message:

LabVIEW:  Failed to load shared library dscProc.dll:ni_lvdsc_process_GetProcessListEnd:C. Ensure that the library is present on the RT target. Use MAX to install NI software or FTP to transfer custom libraries to the RT target.

Those are bad instructions, as it's impossible to install DSC libraries on RT targets either through MAX or FTP.

Suggestions

• Break the VI if an unsupported subVI is added.
• Give correct error messages (e.g. "Function not supported in current target." -- mimicking the FPGA error when attempting to use DBL types)
• Hide the DSC module from the RT palette/quick-drop. Unsupported functions are hidden in the FPGA palette, but not the RT palette. (Well, some are hidden, like "Play Sound File", but not others, like "Get Process List"):

[Bob_Schor]

Don't fret -- Darren just sent me the same message ...

BS

[Sam_Sharp]

As a test, I tried to place a .NET constructor node (something that obviously isn't supported) in RT and it doesn't appear in the palettes/quick-drop and if you copy + paste onto an RT VI you get the 'node not supported in current target' - so this is the expected behaviour.

So either:

- It *is* possible to run DSC functions on RT (somehow...) - I mean if it's just a call library function node inside then the node itself would work if there was a compatible DLL on the target. In theory you could even write your own DLL that has these functions! (I think the point I'm trying to make is that there is no reason that the VI itself can't execute on RT, or at least, it isn't detected by LV that it isn't supported, other than the fact it depends on an external library and that there is no such DLL for DSC on RT)

- It's a LabVIEW bug (for which a CAR should be raised) that the RT palette shouldn't have these items

The actual idea though that I think is interesting and would have given kudos for though is that the error messages about missing components needs to be improved globally - but not just on RT.

Examples:

- Loading a project when you have a missing/uninstalled toolkit (I think?)

- An installer or executable that is missing a component when you try to run the executable ("missing SubVI from ni_aalbase.lvlib" or missing NI-VISA, System Configuration)

- Calling some functionality on RT when the necessary component isn't installed (e.g. HTTP Client or Shared Variable engine)

It would be great, when deploying an RT VI to a target (either in development mode or an RTEXE), if it checked that it had the necessary components/libraries installed - rather than not finding out about it until runtime. It would also be good if there was a 'component dependencies' page in the RTEXE build specification which told you (like installer build specs in LV2013 onwards) which components are required by the RT application.

I don't agree with breaking the VI just because a component isn't installed - you might be developing for simulation or multiple targets with different components installed.