#WriteProfileString
4 messages in this thread
Don,
I've discovered that if you use WriteProfileString while WIN.INI is also
an open file in an app, a lost chain is created on the disk drive. When you
look at this lost chain, it will always start with whatever data
WriteProfileString was writing to win.ini. Perhaps there needs to be a
warning somewhere that win.ini cannot be an open file whenever this api
call is used.
Along these lines, is there any way to prevent WriteProfileString from
completely re-writing win.ini to disk and re-reading it after every
WriteProfileString call? In my case, I manipulate the softfont section of
postscript ports in win.ini and this can entail adding as many as 175 lines
per port to win.ini. Using WriteProfileString to do this takes an eternity
so I've had to resort to reading win.ini as a binary string and doing my
own parsing/manipulation with a single call to WriteProfileString at the
end.
–dennis
There is 1 Reply.
Hi Dennis,
I doubt there is no way to tell WriteProfile* functions to only write the
new information. It would do this if it could since this would be mush more
proficient.
I will also look at reading and open file with Profile functions.
Thanks.
Don Funk
There is 1 Reply.
Oops, sorry if I mislead you. The problem is not reading but writing
profile functions while the target ini file is also an open file in the
app. If you use a Write profile function while the target ini file is open
in the app, the output of the write profile function ends up in a lost
chain. If you need some sample code, let me know.
–dennis
There is 1 Reply.