LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

What does the open file dialog do 'under the hood' and is there a way to simulate it

What does the open file dialog do 'under the hood' and is there a way to simulate it?

 

I have a bug in my code (that I've posted about before, here) which I can't fix at the moment, but I do have a workaround.

 

Briefly, the bug:

 

I call a dll from a function node, to initialise and run a spectrometer. If I start up the PC, LabVIEW and run my vi the code runs without complaint, the first call to the dll to initialise the spectrometer doesn;t return an error but the spectrometer is not detected either.

I've tried various solutions, see the link above, and none work

 

 

The workaround:

 

If, at any time before running the code containing the function node I open an 'open file' dialog window, select the dll and click ok/hit enter then everything is fine. When I run the main code the spectrometer is detected.

I use an express vi to open the file dialog, I specify the start path and file name as constant inputs and just click ok/hit return when the dialog pops up. I don't do anything with the dialog outputs. In fact the vi that contains the open file dialog can be run before the project containing the bug is even open.

I have to do this everytime I turn the PC on.

 

So, either

1) Can somewone suggest a fix for the original bug?

2) What is the easiest way to simulate the enter keypress when the open file dialog pops up

or

3) Can someone tell me what the open file dialog does under the hood that somehow causes the dll to work and can it be simulated in straight LabVIEW

 

I suspect that the dll itself is dodgy ( I have in the past talked to the supplier but not got very far, and I will try again but I would like a quick, temporary solution too). I'm guessing that the file dialog is making some kind of check on the file, and possibly registering its presence with the OS (winXP). I tried using the file/folder exists vi to see if checking the file like that worked but no luck.

 

Any help greatly appreciated.

Dave

 

 

 

 

 

0 Kudos
Message 1 of 7
(3,248 Views)

I've seen this happen before as well. I'm not 100% sure what the file dialog does, but my best guess is that Windows caches the last location a file dialog was used as one of the default application search paths. I think the DLL that communicates with your instrument is trying to load some dependent file (such as another DLL or data file) that can't be found unless this location is part of the search path.

 

I believe some workarounds are to make sure the DLL and any dependent DLLs or files are located somewhere in the Windows search path. This can be next to LabVIEW.exe or your built executable, in System32, or any other location that you have registered as a search path in the Path environment variable on your computer.

 

You can also try using the System Exec function to use the command line to dynamically add the directory where your DLL is to the Path variable at run-time with a command such as:

PATH=%PATH%;C:\Program Files\My DLL Location

Message Edited by Jarrod S. on 11-23-2009 10:36 AM
Jarrod S.
National Instruments
0 Kudos
Message 2 of 7
(3,240 Views)

Hi,

 

Thanks for the reply. I've tried adding the dll loctation folder to the PATH variable, putting the dll in windows\system32 and in the labview.exe folder but none of these have worked I'm afraid.

 

i guess I'll have to go with the work around. What is the neatest way to simulate an enter keypress or left button press on the open file dialog OK button?

 

Thanks

Dave

0 Kudos
Message 3 of 7
(3,160 Views)

I once had a bug that is no going to be the feature you will want:

Call the file dialog with a file name (default name) with the Enter char in it.

 

Felix 

0 Kudos
Message 4 of 7
(3,148 Views)

Hi David

 

I am very conscious about thread hijacking but this sounded like my issue so I hope you dont mind me asking about your issue. I am hoping that you have a spectrometer from the same vendor as me and its not just me seeing an Error 1097 issue. My spectrometer is from a company called Stellarnet.

 

 

So far I have unable to get it to work with other VIs. There is one condition where I can get it to work but its no good for me.

 

Case 1

  

I open the VI in a fresh labview environment with no other VIs in memory. The code runs with no issue.

 

Case 2

 

Labview is not opened. I double click the spectrometer VI in windows explorer.  The VI opens but it fails to run resulting in Error 1097. Personally, I dont see the difference between this and Case 1 above and yet it fails.

 

Case 3

 

If I already have other VI's in memory and try to load the spectrometer VI and run it fails with Error 1097. This case is the one that most important to me. I have a test executive that will load test VIs dynamically and I can't get this to work. Same problem Error 1097.

 

 

I wanted to share what I have seen with you and to let you know that maybe somebody else has the same issue. I am convinced its the DLL but the vendor dis-agreed saying it was LabVIEW. I couldn't convince him otherwise.

 

Thanks in advance

 

David

 

 

 

0 Kudos
Message 5 of 7
(3,135 Views)

Felix: Thanks for the tip. It dosn't quite work though. When I add any of \n, \r, \t to the end of the default name the file dialog closes and returns error 43, dialog cancelled by user, and the file isn't checked, ie the 'exists' boolean is false.

 

David: My spectrometer is from a different company, Andor. I only get error 1097 when I turn on maximum error checking. With default error checking, the dll appears to run ok, but doesn't detect the spectrometer. It makes no difference how I start the VI.

 

Have you tried my workaround, ie load the vi directly (your case 2), open the call function library node, reselect the dll and then run the VI. Does it work then?

 

Also try what others have suggested in this and the original thread, ie trying to register the dll, putting it in the same folder as LabVIEW.exe

Message 6 of 7
(3,084 Views)

Hi David,

 

Thanks very much for letting me know.

 

I have tried most of that stuff except placing the DLL in the same directory and enforcing a re-load of the DLL. In the latter case I had the same issue with a different instrument type so thanks for reminding me about that again.

 

cheers

 

David

0 Kudos
Message 7 of 7
(3,079 Views)