Fail gracefully with missing DLLs

[jmorris]

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

[tst · Accepted solution]

1. Nice job on testing some unusual conditions. Just having the mindset is a good thing.
2. 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.
3. 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.
4. 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.

[nathand]

The easiest solution is to configure the Call Library Function Nodes so that you provide the DLL path as an input. Then you can check if the library exists before you try to call a function from the DLL. The downside is that the first call to the DLL will be much slower because it will load the library.  Successive calls might be slightly slower too due to checks to see if the library is loaded, I'm not sure.

[jmorris]

Hi tst, thanks for your quick reply!

I agree it is probably not worth putting into the Idea Exchange.  I did consider that, but like you said this is a situation that I hope will never actually happen "in the wild", just in my test suite.  The main reason I'm changing the code is I don't want my test procedure to read "Rename one of the missing files, and start the application.  Expected result: Ugly."  LOL

I like your idea of loading my entire application from a small EXE which just tests for the presence of necessary files.  That's a lot easier than dynamically loading each VI that calls the DLLs!  I will probably go with that solution the next time I have funding to update the code.

Thanks,

-Joe

[jmorris]

Hi nathand, thanks for the heads up on a simpler solution, as well as the possible drawbacks.  Since I need the DLL calls to be relatively fast, I'll probably not use that solution this time, but it's good to have options!

-Joe

[jyang72211]

can we do something like that?  See attached.

[nathand]

---

@jyang72211 wrote:

can we do something like that?  See attached.

---

I think you posted in the wrong thread.

[jyang72211]

Sorry, posted the wrong picture.  here it is again.

[jmorris]

jyang - Yes, that is probably what I will do to verify the DLL exists.  However, the trick was that all the non-user-friendly dialog boxes were occurring before any of my code could run.

[tst]

---

@jyang72211 wrote:

can we do something like that?

---

Yes, but the point is that the links to the DLLs are static, so they need to be changed somehow to be loaded dynamically, and the easiest change is probably to load the main VI or the entire executable dynamically.