View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001772 | JEDI VCL | 00 JVCL Components | public | 2004-05-14 00:42 | 2004-05-14 04:38 |
| Reporter | csterg | Assigned To | marcelb | ||
| Priority | normal | Severity | block | Reproducibility | always |
| Status | resolved | Resolution | no change required | ||
| Product Version | |||||
| Target Version | Fixed in Version | ||||
| Summary | 0001772: TJvAppIniFileStorage overwrites ini file | ||||
| Description | Upon 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!!! | ||||
| Tags | No tags attached. | ||||
|
|
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); |
|
|
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. |
|
|
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? |
|
|
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). |
|
|
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. |
|
|
I cannot find this property in jvcl3 beta 1. Is it in newer CVS files? |
|
|
I cannot find this property in jvcl3 beta 1. Is it in newer CVS files? |
|
|
Yes, sorry, didn't notice that. Anyway these two properties where added specifically for this kind of problems. |
|
|
OK then, I think that this is good enough. I believe we can close this issue. Thanks |
| 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 |
