TMS's FormSize component saves aForm's size and position in an .ini file. This file's path is开发者_Go百科 stored in the component's SaveName property. I would like to assign FormSize.SaveName to a file in the user's AppData folder. I can find the AppData path in my source code.
Does anyone know where (in my code) I assign the AppData path to FormSize.SaveName? I am thinking the FormSize component is created, and a default SaveName initialized, BEFORE aForm is created. In other words, FormSize loads the config file BEFORE aForm's FormCreate event fires; assigning a value to FormSize.SaveName during aForm.FormCreate is too late.
Thanks, as always.
The adjustment of the form is done in the Loaded
method of TFormSize
, not when you change the SaveName
property (although it has been read from the DFM before).
If you set the properties SavePosition
and SaveSize
to false during designtime, there will nothing be loaded at runtime. In that case you can manually load and save the settings at a convenient place in your code by calling LoadFormSettings
and SaveFormSettings
.
I'd expect SaveName to be stored in the .dfm file, so it should be assigned to the component at load up.
If you want to determine the save name in code, it should probably be early in the cycle. I just checked a few possibilities:
- In the form's constructor (override), before the call to inherited;
- in the form's constructor (override), after the call to inherited;
- in the form's FormCreate event handler;
- in the form's Loaded procedure (override), before the call to inherited and
- in the form's Loaded procedure (override), after the call to inherited.
Possibilities 4 and 5 worked as expected. 3 and 2 did nothing and 1 caused an AV. So David's suggestion seems to be fine.
"assigning a value to FormSize.SaveName during aForm.FormCreate is too late."
I had a similar requirement to modify a component's property owned by a module. The standard "Create" event was too late given the loaded property was already in effect.
Properties persisted in the DFM are assigned (or cached) during the call to the protected virtual ReadState procedure. Conventionally, cached properties are activated during the protected virtual call to Loaded. Both ReadState and Loaded can be overridden.
In my case, I wanted to make sure TADOConnection's Connected property was false in the release build. During development, the component's property is normally true given design needs of dependent data sets.
It was a pain having to set the property to false prior to checking-in the code for subsequent builds/deployment. So instead, I overrode the Loaded method and hacked the streamed property value to false.
interface
type
TMyDataModule = class(TDataModule)
MyAdoConnection: TADOConnection;
protected
procedure Loaded; override;
end;
implementation
type
TADOConnectionHack = class(TADOConnection) end;
procedure TMyDataModule.Loaded;
begin
TADOConnectionHack(MyAdoConnection).StreamedConnected := False;
inherited Loaded;
end;
精彩评论