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:
12-15-2022 07:43 AM
Nope, not an odd directory issue. When you launch the PROGRAM_A from PROGRAM_B through LaunchExecutable() is is launched as child process. That means it inherits all kind of attributes from the launching program including the current directory setting. This current directory setting is used to complete relative paths in the C runtime library.
Under a multitasking OS like Windows, a current directory settings is a real anachronism, but in the interest of backwards compatibility it was maintained. However Windows has various particularities such as when you open the standard file select dialog in an application, the current directory setting will be updated to the directory it was in when the dialog is dismissed. It makes the current directory completely unreliable for any GUI process.
Explorer goes through some extra hoops to set the current directory of a process to the actual directory you were in when double clicking an executable. This is usually the same directory that the executable is located in (unless you happen to have shortcuts or symlinks or similar).
So as summary: Using relative paths to reference a file in a GUI application is asking for real problems if that application also allows to open a file select dialog. And even if it doesn't, the current directory it may use to resolve such a path will depend on how the executable is launched.
If you reference files on disk you should NEVER use relative paths. If you know it is located in the same directory as your executable, determine the path for the directory your executable is in, append the file name and then open the file with an absolute name.
12-15-2022 07:51 AM
Well said, also know that the permissions for the ini files present with your executable may not allow writing, depending on Windows version.
I used to create distributions of my programs to distribute and include an ini file with them for their settings, to be installed in the same directory.
That started failing with Win7 (I think ?) as a program can no longer write in c:\Program Files, even in its own directory. You now have to go through all kinds of hoops to figure out where the user's home dir is and save there.