Prevent a Missing DLL in Call Library Function Node from Breaking Execution

[Andi_S]

If a DLL is configured in a Call Library Function Node and is either missing or defective, the entire program cannot be executed. In most situations, this behavior is acceptable.

However, it can also be quite frustrating, especially if the part of the program that uses the DLL is not called. Additionally, it would be helpful for debugging purposes if the program could still execute even when a DLL is unavailable.

Therefore, I propose that the configuration dialog of the Call Library Function Node includes an additional checkbox labeled "Break execution if DLL cannot be loaded." If this checkbox is checked (default setting), the behavior will remain as it currently is. If the checkbox is unchecked, the program should run until the affected node is executed. At that point, the node's error output should indicate either "DLL not found" or "DLL found but cannot be loaded," and execution should proceed beyond the node. In this scenario, it will be the programmer's responsibility to handle the error appropriately.

As an extension of this idea, I could also envision a new entry in the LabVIEW.ini / application.ini file to assist with debugging. If this entry is not present, the explicit configuration of the node will be used. If it is available, it will override the explicit configuration with either true or false.

Please also see this related idea: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/get-DLL-path-from-the-call-library-function-node/idi-...

[reddog]

I'm not sure if it completely voids the idea or not, but if you click the "Specify path on diagram" checkbox and wire the path from the diagram, you will get run time errors instead of edit time errors if the dll cannot be found or loaded. I just wanted to make sure others were aware that to some extent this behavior already exists.

[Andi_S]

I know this checkbox, but that's not what I'm suggesting. I want to be able to configure the DLL without having to connect a path at the input. However, I agree with you that "my suggestion" would behave like when the path input is enabled.

[wiebe@CARYA]

But you can configure a CLFN without setting a library name or path. (?)

This will indeed break the VI, which is solved by providing a path on the diagram.

That is actually a key difference between specifying the path on the diagram vs specifying it in the CLFN.

Note that the path on the diagram supports everything, including wildcards, the CLFN path does.

It seems to do exactly what you're asking for, although it requires 1 wire and 1 constant...

[Andi_S]

I do not totally agree ... when creating an executable, LabVIEW does not automatically choose the correct version of the DLL and does not copy it to the support folder in case that I specify it by a constant.

[wiebe@CARYA]

I concur.

That is a 'minor' difference that could indeed have major implications.

I use a conditional disabled case (only 1 CLFN is required) to make my exe use a static path. Works fine for building an .exe, but not for a .ppl... (We can't really win here...)

Of course that will break the build if the dll isn't there.

I wander about the scenario though. You want the code or exe to run without the dll, but the build should include the dll?

What will happen if the suggested option is on and the dll is missing? Would the build fail or build without the dll?