Fail gracefully with missing DLLs

Question

Hello again all you helpful forum-goers!
The Situation:
I have an application which includes a few subVIs which call two DLLs via Call Library Function Node VIs.  After building the application and putting the executable and the two DLLs on another computer, I tested what happens when the DLLs are mis-named or otherwise not present.
The Current Unfortunate Results:
What happens is that the Loading VIs LabVIEW dialog comes up, and on top of that a standard open/save dialog box saying "Find the shared library named MyDLL.dll".  If I then press Cancel, another dialog box comes up saying "LabVIEW: Resource not found.  An error occurred loading VI 'UseMyDLL.vi'.  LabVIEW load error code 3: Could not load front panel."  When I press OK to that, I get the same dialog box, once for every VI that calls the DLL.  After pressing OK a few more times, I get a list of every place the subVIs that call the DLLs are used, with lines like "Missing subVI UseMyDLL.vi in VI MyTopLevel.vi.".  At the same time my front panel appears, but with the toolbar showing and broken run arrow.
What I Want to Happen:
What I was hoping would happen is something like a dialog appearing asking to find the DLL, and if Cancel was pressed a dialog saying "MyApp.exe could not be run because the file "MyDLL.dll" is missing.", and then nothing else happening or being shown.  Honestly, I'd rather it not even prompt the user to find the file.  It feels very unpolished for a distributed application.
The Question(s):
Does anyone know a good way to get results closer to what I want to happen?  The best idea I've been able to come up with is to dynamically load the VIs which rely on the DLLs, so that I can programmatically verify the DLLs are there before loading those VIs, and exit gracefully using my own code.  Would there be any problem with using Call by Reference or Invoke Node to call the VIs when I want the DLLs to remain in memory once they are loaded to save their state, and some of the VIs which call the DLLs need to remain in memory because they are functional global variables?  Seems like there might be some gotchas there.  I'd be happy to hear any other possible solutions to the missing DLL behavior problem, especially solutions that do not require as much of a rewrite of the code.  ;-)
Thank you as always for your time!
-Joe
Solved!
Go to Solution.

Answer 1

Nice job on testing some unusual conditions. Just having the mindset is a good thing.
I don't think that the nice-loading behavior you want can be applied globally because sometimes DLLs are loaded by dynamically called code and that shouldn't affect the application, but it probably could be applied to static code called by the main VI in the executable.
That said, it might not be worth it, because this is a relatively rare occurence. If you put the idea in the idea exchange I will vote for it, but I wouldn't lose any sleep if NI didn't spend any resources on it.
You could load the VIs dynamically as you suggested, or you could configure the CLN nodes themselves to accept a dynamic path to the DLL, but I would argue that this problem is rare enough not to warrant changing the code. If you really care that much, you could load your application through a start up VI or EXE which will test for the presence of the DLLs and only if all of them are found will then dynamically load the main VI or EXE.
Try to take over the world!