[DUG] Usage - initialization and finalization

[Paul A Norman]

Many thanks Kyley,

I think I have a good overview of it all now, thanks also to your and Carl's
dialogue!

Paul


On 23/05/06, Kyley Harris <kyley at harrissoftware.com> wrote:
>
>   Yes. The application object does exist, so in my last post I definitely
> typo'd saying it does not exist. Sorry.
>
>
>
> In a normal application the Application Var is created in Controls.pasinitialization.
>
>
>
> But be aware that your entire application is generally executing from the
> Application.Run context, so anything outside of this may not behave as you
> expect such as receiving windows events and such. Not that I've tested that
> because I wouldn't use finalization or initialization for anything other
> than basic things
>
>
>
>
>
>
>  ------------------------------
>
> *From:* delphi-bounces at ns3.123.co.nz [mailto:delphi-bounces at ns3.123.co.nz]
> *On Behalf Of *Paul A Norman
> *Sent:* Tuesday, 23 May 2006 5:41 p.m.
> *To:* karlreynolds at xtra.co.nz; NZ Borland Developers Group - Delphi List
> *Subject:* Re: [DUG] Usage - initialization and finalization
>
>
>
> P.S. the Application object is used whcih some one earler suggested was
> not possible.
>
>
>
> The application does work!
>
>
>
> On 23/05/06, *Paul A Norman* <paul.a.norman at gmail.com> wrote:
>
> Just back in the basics where I am for a moment,
>
>
>
> This is some code I found following a link that Stefan suggested in
> another thread today.
>
> What is the benefit of doing it all in *initialization* and *finalization*  if
> it were contained in a form unit (which it was not incidentily)?
>
>
>
> initialization
>   begin
>     TComObjectFactory.Create(ComServer, TOurNSHandler, Class_OurNSHandler,
>       'OurNSHandler', 'OurNSHandler', ciMultiInstance, tmApartment);
>
>     Table := TTable.Create(nil);
>     table.DatabaseName := ExtractFilePath(Application.ExeName);
>     table.TableName := DatabaseFile;
>     table.active := true;
>   end;
>
> finalization
>   table.free;
>
>
>
>
>
> On 23/05/06, *Karl @ Work* < karlreynolds at xtra.co.nz > wrote:
>
> > I'm curious as to why each of your consuming units needs to keep a
> > reference to the singleton?
> >
> > IMHO, surely the whole point about a singleton is that you don't keep
> > references per se to it.
> >
> > When you need to access the singleton, you should just call your
> > Singleton function declared in your MySingletonUnit unit?
> >
> > Surely that would result in a whole lot less reference counting, and
> > worrying about who's holding on to it and when they drop their
> > references, etc.
>
> I would prefer not to keep references to the singleton in the consuming
> units, it's just that I haven't found another way to ensure that it will
> free itself both (a) after everything else has finished using it and (b)
> before the program finishes.  The problem is that the singleton can't be
> cleaned up in the finalization of its own unit because there are still
> references to it which are accessed after that.
>
> Cheers,
> Carl
>
>
>  _______________________________________________
> Delphi mailing list
> Delphi at ns3.123.co.nz
> http://ns3.123.co.nz/mailman/listinfo/delphi
>
>
>
>
>
>
> _______________________________________________
> Delphi mailing list
> Delphi at ns3.123.co.nz
> http://ns3.123.co.nz/mailman/listinfo/delphi
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ns3.123.co.nz/pipermail/delphi/attachments/20060524/d1cae921/attachment-0001.html