As you may have seen, I did manage to finally solve the problem. I
start all my projects with a template I've setup and so I always have MainF1
as my mainform no matter how I set it up or use it, and also I never need
worry about creating more than one instance of it per application.
Back in Delphi 5 or 6 it was, I began having problems in the freeing
of dynamically created forms not completely releasing owned components of
their own, and so I did some experimentation and found that 'Release' wasn't
as sure a method as I had assumed. That's how I began pre-initializing
every form and other object types as nil...just to remind me that I would
need to reset to nil after it was freed...and it provided a good test to
make sure I didn't try freeing an object that had already been freed, or
creating one that had already been created and was still hanging around.
At first I had to do it all with two calls, one to free the object
and another the set it to nil, but then Borland must have heard me because
suddenly they added FreeAndNil to the language!
As for calling the DataModule.Destroy method directly, this has
never failed me before. I would call the method at whichever point in the
application I wanted to get rid of it, and then in the OnDestroy event would
again use FreeandNil AFTER all my cleanup code in the OnDestroy method had
run. It's only just now that I suddenly ran into this so I'm really not
sure why. But I do know that it gets confusing when there are so many
different ways to accomplish the same things...some doing a little more, and
others a little less! Like in many databases where you can shut it down by
calling it's close method, or setting it's connection property to False
which then also disables any connected tables. I've never understood the
rationale behind things like this!
from Robert Meek dba "Tangentals Design"
e-mail: [EMAIL PROTECTED]
Freelance Windows Programming for XP and Vista
Also proud to be a Moderator of the "Delphi-List" at elists.org
"Reality cannot be explained...only enjoyed or endured as your current
perspective allows!"
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Luthfi Hakim
Sent: Friday, September 28, 2007 8:48 AM
To: [email protected]
Subject: Re: CodeGear D7 patched to ver 3
Hello,
The problem probably caused by the application trying
to free object(s) that already been freed, either by
you (in the main form's OnClose event) or by the owner
of the object. Just remember that if you create a
control with owner other than nil then the owner will
free the control on its destructor block.
So you need to remove codes that doing this (if you
created them with Self (i.e. the mainform) as the
owner):
> then tested to see if they are nil or not in
> the mainform's OnClose event, and if they
> are not nil, their individual
> FreeAndNil(IniFile), DataModule.Destroy, and
> InterfaceF.Close methods are called.
Btw, you should not call DataModule.Destroy. The safer
methode is DataModule.Free. Also I personally prefer
InterfaceF.Free instead of InterfaceF.Close, unless
you do cleaning up in OnClose event or you want to use
OnCloseQuery event.
>In it's ExitActionExecute, if I use MainF1.Close
I think it's safer to use Self.Close here. Since there
is probability that in the future you will use another
instance on TMainF1 which is not MainF1.
Regards,
Luthfi
____________________________________________________________________________
________
Catch up on fall's hot new shows on Yahoo! TV. Watch previews, get listings,
and more!
http://tv.yahoo.com/collections/3658
_______________________________________________
Delphi mailing list -> [email protected]
http://www.elists.org/mailman/listinfo/delphi
_______________________________________________
Delphi mailing list -> [email protected]
http://www.elists.org/mailman/listinfo/delphi
