Making sure MainForm gets closed last?

Dear Group,

I've run into the following problem:

I'd like to store the state of different listviews (columns shown, width of
columns, etc.) in my program.
I'd like to store the data in the database, so if the user logs-on from
another computer the similar state is shown.
Currently, all listviews store their own data upon FormDestroy event in a
separate .ini file. The .ini file would be put into a database blob, but
here comes the problem:

MainForm, which would be responsible for storing data in the DB, gets closed
before its child forms.

Now my question is:
If I make Application the owner of the current child forms of MainForm, will
all these forms be closed before the MainForm?

Is there a rule for the order in which Application own forms are closed?

If all Forms are own by the Application object, and MainForm is the first
form created, will MainForm be the last form that gets closed?

Thanks for the help!
Veronica

On Wed, 6 Aug 2008 11:40:05 +0200, Veronica Mae wrote:

> Is there a rule for the order in which Application own forms are closed?
If the user closes the main form then it will be closed first.

I would suggest putting the code somewhere else like FormDestroy or
adding a call to a function after Application.Run in your .dpr file.

--
Marc Rohloff [TeamB]
marc -at- marc rohloff -dot- com

"Veronica Mae" <veronica@nospam.com> wrote in message
news:48997181@newsgroups.borland.com...
>
> MainForm, which would be responsible for storing data in the DB, gets
> closed before its child forms.
>
> Now my question is:
> If I make Application the owner of the current child forms of MainForm,
> will all these forms be closed before the MainForm?
>
> Is there a rule for the order in which Application own forms are closed?
>
> If all Forms are own by the Application object, and MainForm is the first
> form created, will MainForm be the last form that gets closed?


You can avoid this kind of problem (dependence on visual components and
order of creation/destruction) by putting processing code in non-visual code
units or classes.

In this case I would create a small class (descended from TObject) that each
listview can call to save its state. It can still be in "ini" format either
by this new class providing an TInifile object, or the listview passing the
TInifile it is currently using to this new class. This new class can then
take care of writing the data to the database - and on start up reading it
back on request from the listview controls. The lifetime of this non-visual
class is *completely* in your control.

--
Wayne Niddery - TeamB (www.teamb.com)
Winwright, Inc. (www.winwright.ca)

Hi Marc,

I've changed the code, so the DB update is in MainForm's FormDestroy.
All other Forms belong to the Application and they're created after the
MainForm.

Does this guarantee that all the other forms' FormDestroy will be called
BEFORE the MainForm's FormDestroy?

Thank you:
Veronica

"Marc Rohloff [TeamB]" <marc@nospam.marcrohloff.com> az alábbiakat írta a
következo hírüzenetben: r5yatdiw6dc6.dlg@dlg.marcrohloff.com...
> On Wed, 6 Aug 2008 11:40:05 +0200, Veronica Mae wrote:
>
>> Is there a rule for the order in which Application own forms are closed?
> If the user closes the main form then it will be closed first.
>
> I would suggest putting the code somewhere else like FormDestroy or
> adding a call to a function after Application.Run in your .dpr file.
>
> --
> Marc Rohloff [TeamB]
> marc -at- marc rohloff -dot- com

Dear Wayne,

A good idea, but slightly problematic.

All the DB components are on the MainForm including DBConnection and DBQuery
I use to save the listviews' states in the DB.

If MainForm gets destroyed, DBConnection is destroyed as well and the
connection is lost.

So the new class should have its own DB components.
But estabilishing a connection with the server takes a few seconds, so if I
was to create a new connection upon closing the application, there would be
a noticable delay after pressing the close button...

Any ideas on how to solve this?

Thanks:
Veronica

"Wayne Niddery (TeamB)" <wniddery@chaffaci.on.ca> az alábbiakat írta a
következo hírüzenetben: 4899a1d5$1@newsgroups.borland.com...
> "Veronica Mae" <veronica@nospam.com> wrote in message
> news:48997181@newsgroups.borland.com...
>>
>> MainForm, which would be responsible for storing data in the DB, gets
>> closed before its child forms.
>>
>> Now my question is:
>> If I make Application the owner of the current child forms of MainForm,
>> will all these forms be closed before the MainForm?
>>
>> Is there a rule for the order in which Application own forms are closed?
>>
>> If all Forms are own by the Application object, and MainForm is the first
>> form created, will MainForm be the last form that gets closed?
>
>
> You can avoid this kind of problem (dependence on visual components and
> order of creation/destruction) by putting processing code in non-visual
> code units or classes.
>
> In this case I would create a small class (descended from TObject) that
> each listview can call to save its state. It can still be in "ini" format
> either by this new class providing an TInifile object, or the listview
> passing the TInifile it is currently using to this new class. This new
> class can then take care of writing the data to the database - and on
> start up reading it back on request from the listview controls. The
> lifetime of this non-visual class is *completely* in your control.
>
> --
> Wayne Niddery - TeamB (www.teamb.com)
> Winwright, Inc. (www.winwright.ca)

Veronica Mae wrote:
> I'd like to store the state of different listviews (columns shown, width of
> columns, etc.) in my program.
> I'd like to store the data in the database, so if the user logs-on from
> another computer the similar state is shown.
> Currently, all listviews store their own data upon FormDestroy event in a
> separate .ini file. The .ini file would be put into a database blob, but
> here comes the problem:
>
> MainForm, which would be responsible for storing data in the DB, gets closed
> before its child forms.
>
> Now my question is:
> If I make Application the owner of the current child forms of MainForm, will
> all these forms be closed before the MainForm?
>
> Is there a rule for the order in which Application own forms are closed?
>
> If all Forms are own by the Application object, and MainForm is the first
> form created, will MainForm be the last form that gets closed?

Why does it matter?

Before you save the column states to the database, close or destroy all
the other forms.

--
Rob

On Wed, 6 Aug 2008 15:06:21 +0200, Veronica Mae wrote:

> Does this guarantee that all the other forms' FormDestroy will be called
> BEFORE the MainForm's FormDestroy?

No, its almost always true but there are ways to make it not so. The
general rule is that, when the program terminates, they get destroyed
in the reverse order they were created (This of course assumes that
they weren't destroyed some other way, either in code or by changing
the FormClose's Action parameter to caFree)

--
Marc Rohloff [TeamB]
marc -at- marc rohloff -dot- com

> Currently, all listviews store their own data upon FormDestroy event in a
> separate .ini file.

Alternatively you can make all listviews register themselves (say
OnCreate), maybe simply by adding themselves to a TObjectList. When your
main form is destroyed you can iterate over that list. In case you
cannot make sure all other forms with listviews still live at that time,
unregister listviews OnDestroy, storing the data there. A
"TListViewData" class probably is handy, which might live longer than
the actual listview (you could manage a list of "TListViewData" objects
instead of a list of listviews).

--
Jens Gruschel
http://www.pegtop.net

I've tried freeing the other forms, but I'm getting a multi-free memory leak
error.

If a form is own by the application, won't calling Form.Free cause a double
free error? (as the Application will try to free the form later...)

"Rob Kennedy" <me3@privacy.net>
> Why does it matter?
>
> Before you save the column states to the database, close or destroy all
> the other forms.
>
> --
> Rob

What are some ways to make it no so?

"Marc Rohloff [TeamB]"
> On Wed, 6 Aug 2008 15:06:21 +0200, Veronica Mae wrote:
>
>> Does this guarantee that all the other forms' FormDestroy will be called
>> BEFORE the MainForm's FormDestroy?
>
> No, its almost always true but there are ways to make it not so. The
> general rule is that, when the program terminates, they get destroyed
> in the reverse order they were created (This of course assumes that
> they weren't destroyed some other way, either in code or by changing
> the FormClose's Action parameter to caFree)
>
> --
> Marc Rohloff [TeamB]
> marc -at- marc rohloff -dot- com