|
|
Windows State Components FAQThis page has some frequently asked questions about the DelphiDabbler Window State Components. You can also try the components' documentation. If you still can't find an answer to your question then you should submit it via the website's contact page. Any answer it will be posted here. Contents
1: Why does my form always centre itself on the screen even when TPJWdwState saved the old position? First note that this problem applies to all the window state components, not just TPJWdwState. This is very probably happening because the form's Position property is set to something like poScreenCenter. For the Window State Components to work the Position property must be set to poDesigned. Delphi seems to act on the Position property after the window state component has set the form size and position, overriding any changes in size and / or made by the component. I suppose the components could be modified to allow the Position property to be overruled. If this would mean the components would change the form's Position property I think that's bad practise. I know there's some disagreement amongst users about this design choice, but I'm sticking with it unless someone can come up with some code to work round the problem without changing the Position property permanently. 2: Why don't the components work if they are created at run time? You are probably using the standard Create constructor to create the component. This does not work properly if called dynamically since it depends on the Loaded method being called to complete instantiation of the component. Loaded is only called for components placed on the form at design time. To get round this problem an alternative constructor named CreateStandAlone is provided. Call CreateStandAlone instead of Create and everything should work properly. A reference to the form that the component is to work with must be passed to CreateStandAlone as a parameter. Here's some sample code you could put in your form's OnCreate and OnDestroy event handlers to restore and save the form's position: procedure Form1.FormCreate(Sender: TObject); begin fWdwState := TPJWdwState.CreateStandAlone(Self); fWdwState.Restore; end; procedure TForm1.FormDestroy(Sender: TObject); begin fWdwState.Save; // No need to free fWdwState: the form does this automatically when it is freed end; This code assumes you are using a TPJWdwState component that has been declared as a field of the form and named fWdwState. The code works for any of the window state components. Note: CreateStandAlone was added in v4.3. 3: Why does the TPJRegWdwSate.RootKey property display numbers in the object inspector rather than symbols like HKEY_LOCAL_MACHINE? Symbols such as HKEY_LOCAL_MACHINE are simply constants representing the numbers that identify different root keys. Here's a list of the possible root keys:
The object inspector is displaying the actual number because it doesn't know about the constant names. You need to enter the correct decimal or hex number from the above table. Prefix hex numbers with a A better way This is all rather unwieldy and not very user friendly. So I wrote the HKEY Property Editor to make it easier to set HKEY values. Download and install this property editor. Once that's done you'll be able to set the value of TPJRegWdwState.RootKey in the object inspector by selecting from a list of constant names. 4: Where does TPJWdwState store my window's state data? The component stores the information in an ini file. Where the file is located changed at version 5.5.0 of the PJWdwState unit. From v5.5.0 more options are available and the defaults are more suitable to modern applications whereas in v5.4.2 and earlier there are fewer options and the defaults are not particularly well chosen. Version 5.5.0 and later There are various possibilities depending on how you have configured TPJWdwState's IniFileName and IniRootDir properties. You should read the documentation of these properties to get an explanation then come back here and look at the table below that gives examples of various property values for a program with full path name
Note that in the above table If you have configured TPJWdwState to automatically restore window state at run time (i.e. AutoSaveRestore property is Version 5.4.2 and earlier There are various possibilities depending on how you have configured TPJWdwState's IniFileName property:
Examples:
It is obvious that none of the above are ideal and it is for this reason that the OnGetIniData event was added. You can handle this event to set the ini file name at run time (along with the name of the ini file section to use if you wish). This overrides the value of the IniFileName property and is guaranteed to be called before the component tries to read or write the ini file. Here's an example of handling OnGetIniData that places the ini file in the
procedure TForm1.PJWdwStateGetIniData(Sender: TObject;
var IniFilename, Section: string);
var
Dir: string;
begin
Dir := IncludeTrailingPathDelimiter(SpecialFolderPath(CSIDL_APPDATA))
+ '/DelphiDabblerEg';
ForceDirectories(Dir);
IniFilename := Dir + '\Config.ini';
end;
5: Why does TPJWdwState raise a "can't write file" exception when it is saving the window state? This exception gets raised when the ini file it uses to record window state information can't be created or can't be written to. This is usually because the program user does not have permission to write to the directory containing the ini file. In versions before v5.5.0 this exception may also be raised if any of the directories in the ini file's path do not exist (v5.5.0 and later try to create non-existant directories). You should change the path to the ini file using either the IniFileName property or the OnGetIniData event. Note that this exception can be raised when you call the TPJWdwState's Save method or, if the AutoSaveRestore property is true, when the program terminates. |