View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0005765 | JEDI VCL | 00 JVCL Components | public | 2012-01-12 16:03 | 2012-02-14 17:10 |
Reporter | RHoek | Assigned To | jfudickar | ||
Priority | normal | Severity | minor | Reproducibility | always |
Status | resolved | Resolution | fixed | ||
Product Version | 3.40 | ||||
Target Version | Fixed in Version | ||||
Summary | 0005765: Optionally use TIniFile in stead of TMemIniFile in TJvAppIniFileStorage | ||||
Description | In some cases (when using multiple TJvAppIniFileStorage components pointing to the same file) it's required to write changed settings immediately to the Ini-file. When using the TMemIniFile, these settings are only written in memory, so an other instance cannot read these settings. When using TIniFile, the settings are written directly. So I think it would be nice to have the user specify a property of the TJvAppIniFileStorage, which allows the user to determine which underlaying Ini-component he/she want's to use. | ||||
Tags | No tags attached. | ||||
|
What about activating AutoFlush and AutoReload? |
|
This will give more IO then only using the direct IniFile approach... Also, when using the AutoReload, it will always reload the file when something is read (as far is I understand the code). It would be nicer to have something check the date/time before reloading the file.... (and compare it to the date/time the file has been loaded the last time). But this way a user can choose... * I think I'll have a try on modifying it localle and see whether there are significant problems.... |
|
Hi, sorry but I do not understand why the IO will be increased in opposit to using the TIniFile. When different users/sources are working on the same file, then there will be no other way then reading the file again (indepent from MemIniFile or IniFile). The idea of checking the date/time of the file (in combination with AutoReload) has merrit and I think this is something we should have a look for. Regards Jens |
|
> Sorry but I do not understand why the IO will be increased in opposit to using the TIniFile. I'm expecting the Windows Ini-routines to be more efficient regarding data reading/writing (because less data is needed to be written/read). I did not test this explicitly... I'm just looking at possible side effects of turning on the AutoFlush/AutoReload features... But it's probably best to assume (with these small files), writing the Ini-files using the TMemInifile vs TIniFile will result in almost the same ammount of IO. (I did see the Begin/Endupdate routine - like TStrings - which will probably lower IO, when using the TMemInifile, to write multiple changes in a single flush...) But most of the time, the ini-file is read, so implementing a last-loadtime vs modifytime of the file, will get rid of this... Thanks! |
|
The AutoReload now verify the timestamp of the file before loading the file. Please check the current svn version (Revision 13193) and give me a feedback. Regards Jens |
|
Oh, great. I'll have a look at it soon (sadly I've some other issues I need to address now) |
|
Any news?? |
|
Tested it today. As far as I can see, this does exactly what I would like (regarding the loading).... |
|
What do you mean with "regarding the loading"? Can we close the issue, did I missed something? |
|
Sorry - yes, it can be closed... |
Date Modified | Username | Field | Change |
---|---|---|---|
2012-01-12 16:03 | RHoek | New Issue | |
2012-01-20 20:23 | jfudickar | Note Added: 0019328 | |
2012-01-20 20:23 | jfudickar | Status | new => feedback |
2012-01-23 09:31 | RHoek | Note Added: 0019345 | |
2012-01-23 09:40 | jfudickar | Note Added: 0019346 | |
2012-01-23 15:01 | RHoek | Note Added: 0019348 | |
2012-01-24 21:46 | jfudickar | Note Added: 0019352 | |
2012-01-26 11:05 | RHoek | Note Added: 0019356 | |
2012-02-11 19:30 | jfudickar | Note Added: 0019386 | |
2012-02-13 17:01 | RHoek | Note Added: 0019405 | |
2012-02-13 18:44 | jfudickar | Note Added: 0019406 | |
2012-02-14 08:30 | RHoek | Note Added: 0019415 | |
2012-02-14 17:10 | jfudickar | Status | feedback => resolved |
2012-02-14 17:10 | jfudickar | Resolution | open => fixed |
2012-02-14 17:10 | jfudickar | Assigned To | => jfudickar |