Mysterious TIniFile Coding Issue 1

[Glenn9999]

I have a program here that's basically been working well. I've chosen to share it, but I get a report back on something from someone. The report indicates that the message in the code below is being triggered.

ProgramPath := configini.ReadString('Configs', 'ProgramPath', 'Error');
if ProgramPath = 'Error' then
  HandleError('ProgramPath not found in ini file.')

The program is distributed with a stock INI file and short of the user going in and completely deleting or changing the tag, the message should logically never appear. Is there something about any of the newer operating systems than XP which makes TIniFile not work properly? The Create line is not too far up the chain from the shown code in terms of logic, so there shouldn't be much of a chance that anything is corrupted in the meantime.

For this program, failure to read this line constitutes a show-stopper, but I can't duplicate it on anything I have, so I'd really be interested if there are issues that I might not be aware of given what I'm using or not?

It is not possible for anyone to acknowledge truth when their salary depends on them not doing it.

 

[Glenn9999]

As I mentioned in the first post, the program is distributed with an associated INI file. It's not being created at all during run-time, but read and edited. The program is designed to read it in the same directory as the program. There are checks for existence of this file, along with a number of other things (which should fail if what is written above is true, this is indicated).

What it looks like is that access to the file in the specific place is not guaranteed, despite this file being distributed with the program and logically being in the same place as the program. This is presenting the problem. What I'm trying to do is solve this without having to completely rewrite the program, which is what the above posts in this thread would seem to indicate.

It is not possible for anyone to acknowledge truth when their salary depends on them not doing it.

 

[whosrdaddy]

@Glenn,

if your program resides directly under the root (not in program files) then it should not be an issue as UAC/Virtualstore only protects system folders.
You only have to make sure that the users have write access to the folder where your application resides.

What seems to be coming out of this is that any associated configuration data files have to be put into the directory path that qualifies as "Application Data", due to the user-unfriendliness of the newer versions of Windows.

Small remark here, this was already the case with XP/ME. The biggest fault that MS ever made was granting XP users administrative access by default (something linux never did btw) and allowed for this scenario. The fixed this "mistake" in Vista. You can read the design guidelines here: Link and you will find the same limitations that are today in place, no writing in the program files folder allowed! In the end it is all about the developer not following the guidelines that created this situation...

/Daddy

-----------------------------------------------------
Helping people is my job...

 

[Glenn9999]

OK, so ultimately the only real thing I can do to maintain the accompanying INI as user-editable is not to allow the program to run under the Program Files folder at all?

It is not possible for anyone to acknowledge truth when their salary depends on them not doing it.

 

[TonHu]

No, move the ini file to either Common to All or Current User Application Data directory, depending on desired use-case.

 

[whosrdaddy]

@Glenn,

that is one option, but better is to split application and configuration/data as stated before (and what TonHu says...)

/Daddy

-----------------------------------------------------
Helping people is my job...