 |
BorlandTalk.com
Borland discussion newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Paul
Guest
|
 Posted: Tue Apr 25, 2006 9:03 pm Post subject: TIniFile - is it thread / process safe? |
 |
|
Hi,
If I have multiple threads or processes reading an ini file using the above
component (never writing), is this safe?
Paul |
|
| Back to top |
|
 |
Frode Nilsen
Guest
|
| Posted: Wed Apr 26, 2006 8:03 am Post subject: Re: TIniFile - is it thread / process safe? |
|
|
Paul wrote:
| Quote: | Hi,
If I have multiple threads or processes reading an ini file using the
above component (never writing), is this safe?
Paul
|
If you only read the file, use TMemIniFile instead.
--
frode |
|
| Back to top |
|
|
Hans Galema
Guest
|
| Posted: Thu Apr 27, 2006 8:03 am Post subject: Re: TIniFile - is it thread / process safe? |
|
|
Paul wrote:
| Quote: | My next question is not quite to do with INI files, but where to find them.
|
It is completely up to you to decide where your program stores it's ini file(s).
| Quote: | If I use GetCurrentDir (and SetCurrentDir), what does this actually mean,
|
That will give the last directory where a fileaction has been done by your
program. When you use relative paths then that info is important. But you
better use absolute paths.
| Quote: | What I want is the INI file to be located in the directory of the
application or DLL,
|
Very good.
Then, if you give the inifile the same name as your program,:
AnsiString IniFileName = ChangeFileExt ( ParamStr(0), ".ini" );
| Quote: | and not in the Windows directory;
|
Very good.
Hans. |
|
| Back to top |
|
|
Paul
Guest
|
| Posted: Thu Apr 27, 2006 8:03 am Post subject: Re: TIniFile - is it thread / process safe? |
|
|
Is the benefit of this variant that on instantiating the component, that the
INI file is in memory and faster to read, and the TIniFile variant searches
the file every time?
My next question is not quite to do with INI files, but where to find them.
If I use GetCurrentDir (and SetCurrentDir), what does this actually mean, is
it scoped to Windows, just the application, and what if its used by a DLL?
What I want is the INI file to be located in the directory of the
application or DLL, and not in the Windows directory; I don't want to hard
code where to find it.
Paul
"Frode Nilsen" <frode (AT) auticon (DOT) no> wrote in message
news:444f2015 (AT) newsgroups (DOT) borland.com...
| Quote: | Paul wrote:
Hi,
If I have multiple threads or processes reading an ini file using the
above component (never writing), is this safe?
Paul
If you only read the file, use TMemIniFile instead.
--
frode
|
|
|
| Back to top |
|
|
Paul
Guest
|
| Posted: Thu Apr 27, 2006 9:03 am Post subject: Re: TIniFile - is it thread / process safe? |
|
|
Thanks.
| Quote: | Then, if you give the inifile the same name as your program,:
AnsiString IniFileName = ChangeFileExt ( ParamStr(0), ".ini" );
|
|
|
| Back to top |
|
|
Frode Nilsen
Guest
|
| Posted: Thu Apr 27, 2006 10:03 am Post subject: Re: TIniFile - is it thread / process safe? |
|
|
Paul wrote:
| Quote: | "Frode Nilsen" <frode (AT) auticon (DOT) no> wrote in message
news:444f2015 (AT) newsgroups (DOT) borland.com...
Paul wrote:
If I have multiple threads or processes reading an ini file using
the above component (never writing), is this safe?
If you only read the file, use TMemIniFile instead.
Is the benefit of this variant that on instantiating the component,
that the INI file is in memory and faster to read, and the TIniFile
variant searches the file every time?
|
The benefit is that you don't lock the file, or have update conflicts
with other's reading/writing the same file.
| Quote: |
What I want is the INI file to be located in the directory of the
application or DLL, and not in the Windows directory; I don't want to
hard code where to find it.
|
ExtractFilePath(Application->ExeName) + "filename.ini" should do the
trick
--
frode |
|
| Back to top |
|
|
Paul
Guest
|
| Posted: Thu Apr 27, 2006 8:03 pm Post subject: Re: TIniFile - is it thread / process safe? |
|
|
Thanks everyone.
| Quote: | ExtractFilePath(Application->ExeName) + "filename.ini" should do the
trick
--
frode |
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
