WPF Control Event List?

[PvdG42]

Probably a simple beginner question, but...
In VS 2008, C# WPF Windows Project: how to find the event list associated
with a given control that has been placed on the form? I note that the
"traditional" double-click the control instance produces the default event
procedure shell, but how/where to find the event list for that control to
create a shell for a non-default event?

Seems it should be a basic feature, but darned if I can find it.

[PvdG42]

I know, bad form to reply to one's self, but I note that SP1 adds the events
button to the Properties Window.

But, how to do it in VS 2008 *without* SP1? I have classrooms and labs of VS
2008 istallations, and it's not feasible to re-image all the boxes in the
middle of a semester.

[Alun Harford]

PvdG42 wrote:

I know, bad form to reply to one's self, but I note that SP1 adds the
events button to the Properties Window.

But, how to do it in VS 2008 *without* SP1? I have classrooms and labs
of VS 2008 istallations, and it's not feasible to re-image all the boxes
in the middle of a semester.

You don't. :-)

Events are generally used in WPF when you're writing custom controls.
Look into WPF commands for more information.

Alun Harford

[PvdG42]

"Alun Harford" <de*****@alunharford.co.ukwrote in message
news:uD**************@TK2MSFTNGP03.phx.gbl...

>
You don't. :-)

Events are generally used in WPF when you're writing custom controls. Look
into WPF commands for more information.

Alun Harford

Really? Perhaps you could enlighten me further by providing a link or two to
articles on the subject, and explain why the events button was put back in
the properties window as part of SP1?

[Alun Harford]

PvdG42 wrote:

"Alun Harford" <de*****@alunharford.co.ukwrote in message
news:uD**************@TK2MSFTNGP03.phx.gbl...

>>
You don't. :-)

Events are generally used in WPF when you're writing custom controls.
Look into WPF commands for more information.

Really? Perhaps you could enlighten me further by providing a link or
two to articles on the subject, and explain why the events button was
put back in the properties window as part of SP1?

The MSDN documentation is pretty good, at:

http://msdn.microsoft.com/en-us/library/ms752308.aspx

In WinForms, if you want 'button-like' behaviour, you would attach to
the click event. In WPF, you re-template a button and set its command
property. This prevents coupling between the UI and the business logic
that runs when you click the button.

Unfortunately, a lot of the stuff in the VS designer (Cider) appears to
be in there because MSFT is very reluctant to make massive sweeping
changes to their programming model. Now that they have, somebody seems
to want to make the commercial decision to try to make it work 'like
WinForms' (much as they did with the webforms designer). For the same
reason, UserControls exist in WPF (and the designer somewhat encourages
their use) but you *really* don't want to use them.

I really hope MSFT will refocus Cider more towards helping developers
make a UI representation of their model and less towards trying to
bridge the gap between WinForms and WPF.

Alun Harford

[PvdG42]

"Alun Harford" <de*****@alunharford.co.ukwrote in message
news:uN**************@TK2MSFTNGP03.phx.gbl...

PvdG42 wrote:

>"Alun Harford" <de*****@alunharford.co.ukwrote in message
news:uD**************@TK2MSFTNGP03.phx.gbl...

>>>
You don't. :-)

Events are generally used in WPF when you're writing custom controls.
Look into WPF commands for more information.

Really? Perhaps you could enlighten me further by providing a link or two
to articles on the subject, and explain why the events button was put
back in the properties window as part of SP1?

The MSDN documentation is pretty good, at:

http://msdn.microsoft.com/en-us/library/ms752308.aspx

In WinForms, if you want 'button-like' behaviour, you would attach to the
click event. In WPF, you re-template a button and set its command
property. This prevents coupling between the UI and the business logic
that runs when you click the button.

Unfortunately, a lot of the stuff in the VS designer (Cider) appears to be
in there because MSFT is very reluctant to make massive sweeping changes
to their programming model. Now that they have, somebody seems to want to
make the commercial decision to try to make it work 'like WinForms' (much
as they did with the webforms designer). For the same reason, UserControls
exist in WPF (and the designer somewhat encourages their use) but you
*really* don't want to use them.

I really hope MSFT will refocus Cider more towards helping developers make
a UI representation of their model and less towards trying to bridge the
gap between WinForms and WPF.

Alun Harford

Thanks very much for taking the time to start my enlightenment process. It's
amazing what books that claim to address WPF *don't* tell you :-)