Re: Public variable not intialized

From: Mark Arkey (markarkey1_at_msn.com)
Date: 05/23/04 

Date: 22 May 2004 22:38:55 -0700

"Maarten Wiltink" <maarten@kittensandcats.net> wrote in message news:<40af1145$0$65124$e4fe514c@news.xs4all.nl>...
> "Mohd Rashid Atan" <mra@pacific.net.sg> wrote in message

> Second, don't use TForm.OnShow. I've never (that's *NEVER*) seen
> a case where it was the right place to do whatever people had
> put there. They always want things to happen exactly once, before
> the user gets to interact with the form. Override and extend the
> constructor; override & extend Loaded; write an OnCreate handler.
> But not OnShow, and not OnActivate either.

I agree that most coders who put an OnShow event on their form
should've overridden the constructor or used OnCreate, and I
*definitely* agree that OnActivate is WAY too overused (don't you love
it when you've got an OnCreate, OnShow, and OnActivate all defined?).
Almost every form I write overrides the constructor for initialization
code, and I'm not sure if I've used OnShow in the last two years.
However, I disagree with the statement that OnShow should NEVER be
used.

There are times when OnShow should be used... most particularly when
you want to do something every time the form is shown! :) The events
are there for a reason... don't throw out the whole event just because
a lot of coders misuse it. A valid OnShow event handler would work
when forms are not freed when the user closes them and then he or she
reopens them later. It could be to display a message, update the
status bar, or set the focus to the first control on the form. Maybe
in the OnHide event, we close datasets, and on the OnShow event, we
want to reopen them. Perhaps, since the form could have been stored
in memory for days on end, we may want to check the date, and update
some fields, or more likely, look at the time and update some fields.

I prefer to create forms when needed and destroy them afterwards, but
there are times when you may want to keep them in memory (something I
avoid like the plague, but I work on inherited code). In such a case,
an OnShow event handler is quite useful.

My argument here is that just because the event is often misused
doesn't mean that it can't be used properly. I prefer to have a
circular saw in my garage even if most tasks I do around the house
don't require it. If my neighbor uses a circular saw to carve a
turkey and causes a big mess (and perhaps some fatalities), well, that
doesn't mean that all circular saws should be banned!

Mark Arkey

Mark Arkey
"What's another word for 'thesaurus'?"
  -Stephen Wright

Relevant Pages

  • Re: Problem with MDI application
    ... OnShow would result in an Exception... ... event to set a checkbox to false in the OnActivate in my MDI application. ... > OnShow without success. ... > (OnPaint makes my application unstable). ...
    (alt.comp.lang.borland-delphi)
  • Re: Public variable not intialized
    ... Your argument about needing OnShow because you have all this bad inherited ... > circular saw in my garage even if most tasks I do around the house ... used for things not belonging there. ... A typical newbie error. ...
    (comp.lang.pascal.delphi.misc)
  • Re: Detect WindowsState
    ... WindowState? ... Should it be on the form's OnShow, OnActivate or ... OnPaint? ...
    (borland.public.delphi.thirdpartytools.general)