CODEWITHSUNDEEP
delphiruntimepersistence
BlitzCrank
BlitzCrank

Reputation: 413

How to persist runtime changes made to Delphi's components?

Every time i add text to a listbox or listview or a button from the editor it appears on every program launch as it should. The question is why when i add them at runtime and then restart the program this items disappear ( text or buttons ). I know the text can be saved in file but is there any other way like its saved default from the editor.

Upvotes: 2

Views: 712

Answers (2)

Martin James
Martin James

Reputation: 24847

Yes, I've been doing this for years. Descend from TForm and override create and destroy. In the dtor, stream out the entire form with Tstream.WriteComponent(), (and call inherited!). Use the form classname, or some derivative, to assemble the filename.

In create, assemble the filename again and check if a stream file exists for the form. If not, just call the inherited create() so that the form is created 'normally'. If the file does exist, call CreateNew() and then stream in the form using Tstream.ReadComponent.

This will effectively save and restore all the published properties. The size, position color, font, text, caption etc. of the form and all its components become persistent. An app will start up looking exactly the same as when it was shut down. Labels, lists, memo text, images etc. are all automagically persisted across sessions without any extra code being written.

If you put your new 'TpersistentForm' class in a unit, you can easily make an existing app 'persistent' by adding your 'persist' unit to the uses clause of the form units, edit the form class from 'TForm' to 'TpersistentForm' and rebuild - an 'instant' persistent application by adding one unit and changing a class.

I use this on nearly all my Delphi apps. It impresses the users no end when an app starts up in the same position, font etc. as when it was last closed. Also, I don't need any code to store configuration data - the file paths etc. in TEdits etc. just pop right back up - I don't need no nasty and complex INI files or registry!

There are downsides, which you will find out if you try this. One is design/development time - you test your half-built app and it works fine, so you add some extra buttons, labels to do new stuff, and re-run the app - the new components are not there! This happens because the stream file saved from the previous run does not contain the properties for the new components :((

Upvotes: 1

David Heffernan
David Heffernan

Reputation: 612904

When you add the text at design time it is saved in the .dfm file and compiled into the program. This does not happen at runtime.

Imagine if it did. It couldn't really operate in the same way because you can't have the executable changing once you have deployed the app. You would not want user settings to be stored in the executable. So these settings really need to be external to the application.

To make this happen you need to implement your own persistence mechanism. You would need to save the runtime added contents to a file somewhere (e.g. under the user profile) and then re-load this whenever the application starts.

Upvotes: 0

Related Questions