"Joel" <joelagnel@gmail.com> wrote in message
news:1160799513.977616.231540@i3g2000cwc.googlegroups.com...
>2 Questions:
>
> (1)
> The documentation says application.run() creates a standard
> message loop on the current thread and "optionally" shows a
> form.

> This is really confusing because I was of the understanding
> that application.run() creates a message loop for the form and
> passes all messages to it.

> If showing the form is optional, and I want to to display 2 forms,
> which form will application.run() pass the windows messages to?

> (2)
> I believe there is an internal WndProc() function internally maintained
> and exposed through events in C#?

> When I inherit from a base class (say System.Control) and my derived
> class being Form, the paint event is "inherited from Control" right, so
> my Form should have its own paint event right.
> But then I've read a book that said OnPaint() of Control is responsible
> for calling the registered event handlers, but how can it call event
> handlers that derived classes have registered? Isn't that the job of
> the OnPaint() method of the derived class (in this case form).

Peter Duniho wrote:
> First, that was so *not cool*. Why in the world did you set the follow-up
> to: field to the dotnet.general newsgroup? Please, if you are posting a
> message to a newsgroup, then replies to that message belong in that
> newsgroup. Conversely, if you think you need to change the follow-up to:
> field to something entirely different from the newsgroup in which you posted
> the message, then you are posting to the wrong newsgroup in the first place.
>
> There's almost never a good reason to set to the follow-up to: field when
> posting.
>
> That said, here's my answer, in the newsgroup in which you originally posted
> (I managed to post it twice to the wrong newsgroup before I noticed that
> you'd changed the follow-up newsgroup on us):
>
>
> "Joel" <joelagnel@gmail.com> wrote in message
> news:1160799513.977616.231540@i3g2000cwc.googlegroups.com...
> >2 Questions:
> >
> > (1)
> > The documentation says application.run() creates a standard
> > message loop on the current thread and "optionally" shows a
> > form.
>
> Yes...if you pass a form to Application.Run() it will show that form for
> you.
>
> > This is really confusing because I was of the understanding
> > that application.run() creates a message loop for the form and
> > passes all messages to it.
>
> A message loop isn't for a specific form. It's for a specific thread.
>
> > If showing the form is optional, and I want to to display 2 forms,
> > which form will application.run() pass the windows messages to?
>
> Whichever one the message is intended for. One need not pass any form to
> the Application.Run method, and passing a form to the Application.Run method
> doesn't affect how messages get processed by the forms, other than the Run
> method doing a little extra handling on the passed-in form so that it
> returns when that form is closed. Messages get dispatched to the correct
> form based on its window handle, just as they do with a normal Win32 program
> with multiple windows.
>
> > (2)
> > I believe there is an internal WndProc() function internally maintained
> > and exposed through events in C#?
>
> Yes and no. There is an internal WndProc somewhere, and you do get
> notification of messages via events. But this isn't the only way to handle
> some events. If there's already a handler defined in the class already, you
> can override that method instead of registering an event handler.
>
> > When I inherit from a base class (say System.Control) and my derived
> > class being Form, the paint event is "inherited from Control" right, so
> > my Form should have its own paint event right.
> > But then I've read a book that said OnPaint() of Control is responsible
> > for calling the registered event handlers, but how can it call event
> > handlers that derived classes have registered? Isn't that the job of
> > the OnPaint() method of the derived class (in this case form).
>
> My (very limited :) ) understanding of how this works is this:
>
> You can either register an event handler, or you can override the OnPaint
> method. In either case, you will get your code to run when a paint event
> happens. The difference is that there can be multiple event handlers, but
> only one OnPaint method.
>
> Personally, I find the concept of multiple paint event handlers to be a
> little odd, since if you really have multiple places in the code handling
> the paint event, it seems like there could be some confusion as to how the
> window actually gets drawn. But I suppose there's probably some situation
> in which this makes sense, and at least with this design it's consistent
> with other standard window messages.
>
> Anyway, what this means is that you can either register an event handler, in
> which case the base Control.OnPaint method calls you and other registered
> event handlers. Or, you can override the OnPaint method itself, in which
> case the base class version isn't called implicitly, so you need to call it
> explicitly to ensure that any other event handlers are called.
>
> Hope that makes sense. I'm still trying myself to understand whether it's
> better to register an event handler or override the method, so I'm not sure
> any of the above necessarily clears things up, as opposed to adding new
> questions. :)
>
> Pete