Rif.: Launched program not reading an INI file correctly

[HowardE]

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:

c:\path\PROGRAM_A

c:\path\PROGRAM_B

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.

Thanks! 

[RobertoBozzolo]

Are you receiving any error when trying to access the ini file in the second program?

[HowardE]

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.   🙂

[HowardE]

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.

Hmmm.....  Weird.

[RobertoBozzolo · Accepted solution]

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.

[HowardE]

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.  🙂

[RobertoBozzolo]

You could also translate relative to absolute paths by calling:

• GetProjectDir () to obtain executable folder pathname
• SplitPath () to separate path in elements (fileName parameters returns the last directory in the path if called on a directory rather than a file path)
• MakePathname () to build up a new absolute path pointing to the file to open