Re: Load/Unload events

From: MikeD (nobody_at_nowhere.edu)
Date: 09/07/04 

Date: Mon, 6 Sep 2004 22:32:33 -0400

"Jezebel" <dwarves@heaven.com.kr> wrote in message
news:OtXvTyFlEHA.3632@TK2MSFTNGP09.phx.gbl...
> > That's incorrect. Loading a form has nothing to do with the form being
> > displayed. You can load a form (using the Load statement) without
showing
> > it. Applying that to your advice, I do agree that the Load event is not
> > where you should be determining whether or not to load the form since
it's
> > already in the process of loading.
> >
>
> We're getting off topic. By definition, loading a form mean instantiating
> its GUI elements (as opposed to initializing, that loads only the code),
and
> is an essential prerequisite to showing it.

But that's not what you originally said. <g> What you said was "That event
is fired when the form is in the process of being displayed" (and you
continued thereafter to say "display"). That's not correct. Displaying a
form and loading a form are two very different things. If you want to think
of this as splitting hairs, fine. But don't force that thinking on others.

And, how is clarifying a point that directly relates to something the OP
asked about getting off-topic? You think Marv should go through life with
misinformation?

> It is quite true that you can do
> this without then showing the form, but as a general practice, why would
> you?

There are lots of reasons to load a form and not show it. Perhaps you never
have, but that doesn't mean there aren't good and valid reasons. I do this
frequently for "work forms" (usually for subclassing). An example is an app
that sits in the tray notification area. You (usually) need to load a form
for the menu and for subclassing, but you don't usually want that form shown
right away. The app might run for hours before the user does something
where the form needs shown. Also, it's frequently recommended that if you
want to use certain controls (like the WinSock control), but not have a user
interface, that you still add the control to the form and then just load the
form and NEVER show it.

Mike

Mike

Relevant Pages

  • Re: UCOMIStream, MSHTML and WebBrowser control Persistence Problem
    ... It is best to retrieve it from the control each time you ... When you load the form, I do not see a Navigate. ... As you are loading the ... >> the DocumentComplete event, you will get into a continuous loop. ...
    (microsoft.public.inetsdk.programming.webbrowser_ctl)
  • Re: UCOMIStream, MSHTML and WebBrowser control Persistence Problem
    ... It is best to retrieve it from the control each time you ... When you load the form, I do not see a Navigate. ... As you are loading the ... >> the DocumentComplete event, you will get into a continuous loop. ...
    (microsoft.public.dotnet.general)
  • Re: UCOMIStream, MSHTML and WebBrowser control Persistence Problem
    ... It is best to retrieve it from the control each time you ... When you load the form, I do not see a Navigate. ... As you are loading the ... >> the DocumentComplete event, you will get into a continuous loop. ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Load/Unload events
    ... Get a life. ... >> is an essential prerequisite to showing it. ... > form and loading a form are two very different things. ... that you still add the control to the form and then just load ...
    (microsoft.public.vb.general.discussion)
  • Re: Load/Unload events
    ... Loading a form has nothing to do with the form being ... You can load a form (using the Load statement) without showing ...
    (microsoft.public.vb.general.discussion)