12-13-2022 01:45 PM
I have an application in CVI2020 that reads a value called PLATF from an INI file to determine what hardware platform the program will test. I set it to popup the value if it reads the only two options - 0 and 1. It seems to work great if I launch it from the desktop on Windows 10. We'll call this PROGRAM_A.
I wrote a new application today (PROGRAM_B) that checks out some hardware on the system and decides whether PROGRAM_A should run either PLATF=0 or PLATF=1. It figures that out, notifies the user, then opens up the INI file that PROGRAM_A will use and writes that value into the correct place in the INI file. I can see that happening and it works swell.
When PROGRAM_B is exiting, it closes all the panels, disposes of the INI handle, quits the user interface and just before the final 'return' to go back to Windows it uses the CVI "LaunchExecutable" function to launch PROGRAM_A. PROGRAM_B exits and PROGRAM_A runs, but it fails to access the INI file. I wondered is it was simply an unclosed handle or something, so I tried a Windows Batch file like:
Same deal. PROGRAM_A detected what it wanted, wrote out the INI file and the PROGRAM_B ran without reading it. Arrgh.
So I then commented out the code in PROGRAM_A that writes anything. It actually doesn't even open up the INI file. It detects what it wants and then exits without telling anyone. In the batch file PROGRAM_B still won't read the INI file. But if I don't run PROGRAM_A first it does.
Any suggestions where to start looking for this? Are there weird CVI rules explain how an INI file might fail to read depending on how a program is launched? I really don't know what to try next short of putting command line arguments in PROGRAM_B.
Solved! Go to Solution.
12-13-2022 04:53 PM
Are you receiving any error when trying to access the ini file in the second program?
12-14-2022 07:39 AM
I added a MessagePopup after trying to access the INI file and it is failing with an error -94. I can go hunt around for a cheatsheet to decode this, or maybe you know of one?
Thanks for the quick reply and reminding me to have tried the obvious. 🙂
12-14-2022 07:46 AM
I found a decoder - Error -94 says the file isn't found. So when I run the program from the directory, the path of the INI file (which is relative - it starts with "..\") works fine. If I put a batch file in the that same directory with a call to the executable, it fails. So somehow, running within a batch file changes the effective start directory. The program doesn't think it's in the directory it's running from.
12-14-2022 08:09 AM - edited 12-14-2022 08:10 AM
The return codes from functions in IniFile instrument are listed in the function help: here the documentation for Ini_ReadFromFile.htm.
What you may want to do is to trace the pathname you pass to the function before accessing the ini file: a MessagePopup may be enough to clarify which pathname the program is trying to access. Keep in mind that a relative pathname is interpreted with reference to the current working directory, which I have found a rather obscure concept (additionally it can vary from time to time depending on which IO functions you call).
In any case it an be get with GetDir () and set wit SetDir () so you have all the instruments to understand what's happening and patch it.
12-14-2022 10:09 AM
Indeed it is some odd directory issue. I will explore it with GetDir() [I didn't know about that] but so much of the program is dependent on relative paths that my ability to fix it all is limited. My suspicion is that within a .BAT file the code thinks it's in a different directory - and as you said - it is a rather obscure thing. Yet another *feature* of Windows. 🙂
12-14-2022 04:53 PM
You could also translate relative to absolute paths by calling: