View Issue Details

IDProjectCategoryView StatusLast Update
0001772JEDI VCL00 JVCL Componentspublic2004-05-14 04:38
ReportercstergAssigned Tomarcelb 
Status resolvedResolutionno change required 
Product Version 
Target VersionFixed in Version 
Summary0001772: TJvAppIniFileStorage overwrites ini file
DescriptionUpon destruction of the object, the TJvAppIniFileStorage overwrites ALL entries in the ini file it is associated with. To reproduce this error, simply drop a component on a form (and a TJvFormStorage to associate with), and on the FormQueryClose event, put some custom code to modify an entry in the ini file (using standar TIniFile method), not one that is associated with Form Placement.
When the program exits, you will notice that your write is lost because the TJvAppIniFileStorage overwrites everything!!!
TagsNo tags attached.



2004-05-14 01:39

manager   ~0004249

Yep, TJvAppIniFileStorage is a buffered storage, meaning it will read the ini file, change it and write it back. If you need to write to the ini file manually, you should use TJvAppIniStorage instead (which provides read/write methods for all primary data types). The path in the read/write methods is formatted as 'sectionname\keyname' so a
  TIniFile.ReadInteger('MySection', 'MyKey', MyDefaultValue;
is translated to
  TJvAppIniFileStorage.ReadInteger('MySection\MyKey', MyDefaultValue);


2004-05-14 01:47

reporter   ~0004250

The TJvFormStorage functionallity is broken that way. If you look it generally, if one only wants to use the TJvFormStorage component to save the Form placement in an ini file he cannot. He is obliged to use the TJvAppIniFileStorage for this case, which enforces that all operations to that .ini file should be performed through this.
This is a generalization that should not occur since it breaks the whole idea of the TJvFormStorage component (and of course breaks code currently in use, which is really really hard to change).
I think that you should be able to use the TJvFormStorage component independently of the TJvAppIniFileStorage component if you wish to store form placement data to an existing .ini file.


2004-05-14 02:19

manager   ~0004252

The one thing requested most often is to make TJvFormStorage use a generic backend mechanism, so one can store to anything, not limit to just the ini and registry. Considering we had other components also storing info (without using FormStorage) we chose to use an additional component framework to handle the storage backend and have the FormStorage and other components use a general approach to save data, regardless of target storage.
  We do realise this break backward compatability between 2.x and 3.0 and current code but it is the best mechanism.
  We might write a descendant of TCustomIni that will write to TJvAppIniFileStorage, so you can have an interface compatable way to still use current code. Would that minimize your issue?


2004-05-14 02:54

reporter   ~0004253

I have another idea:
in the SavePlacement event of the TJvFormPlacement component I can write:

var s: string;
s := JvAppIniFileStorage.FileName;
JvAppIniFileStorage.FileName := '';
JvAppIniFileStorage.FileName := s;

This will force the JvAppIniFileStorage component to reload the .ini file before saving the data so it will not overwrite data that may have changed from when it was created.
Will this work as expected? (though not clear)

To avoid breaking code, in general, there should be an option for the TJvFormStorage component to use an already existing TCustomIni file. Thus, A TJvAppIniFileStorage that just delegates to a TCustomIni file would be a better way to keep current functionallity from breaking (instead of writing a descendant of TCustomIni that will write to TJvAppIniFileStorage, since this would still need code to be changed all over the place).


2004-05-14 03:12

manager   ~0004254

Hmm, just remembered: if you set JvAppIniFileStorage.AutoReload to True, it will always reload the ini file before it starts writing. Setting AutoFlush to True will also make sure any data written is actually flushed to the file immediately.


2004-05-14 03:39

reporter   ~0004255

I cannot find this property in jvcl3 beta 1. Is it in newer CVS files?


2004-05-14 03:42

reporter   ~0004256

I cannot find this property in jvcl3 beta 1. Is it in newer CVS files?


2004-05-14 04:22

manager   ~0004258

Yes, sorry, didn't notice that. Anyway these two properties where added specifically for this kind of problems.


2004-05-14 04:29

reporter   ~0004259

OK then, I think that this is good enough. I believe we can close this issue.

Issue History

Date Modified Username Field Change
2004-05-14 00:42 csterg New Issue
2004-05-14 01:39 marcelb Note Added: 0004249
2004-05-14 01:40 marcelb Assigned To => marcelb
2004-05-14 01:40 marcelb Status new => feedback
2004-05-14 01:40 marcelb Resolution open => no change required
2004-05-14 01:47 csterg Note Added: 0004250
2004-05-14 02:19 marcelb Note Added: 0004252
2004-05-14 02:54 csterg Note Added: 0004253
2004-05-14 03:12 marcelb Note Added: 0004254
2004-05-14 03:39 csterg Note Added: 0004255
2004-05-14 03:42 csterg Note Added: 0004256
2004-05-14 04:22 marcelb Note Added: 0004258
2004-05-14 04:29 csterg Note Added: 0004259
2004-05-14 04:38 marcelb Status feedback => resolved