I've noticed that a number of control events do not fire, even though
they are defined--such as Button.Paint and Label.Click. I've got a
couple of questions about this:

1. How does the control inheritance hierarchy work in the Compact
Framework? Control (from which Button and Label are derived, according
to the documentation) fires these events, so if Button and Label are
derived from Control, the events should be firing, and the On[Event
Name] methods should be called in derived classes as well. But this
doesn't seem to be the case.

2. Is there a list somewhere of defined events that are not raised?

Feel free to point me to an article or another posting answering these
questions--I searched on here for a while and couldn't find the answers
to these questions.

Thanks,
Myron

The documentation for events is, well, not very good at this point. You
usually determine which events are actually supported just through trial. I
don't know of a list that states which events are truly supported, however,
you may want to look to the class library comparison tool to see if that
helps.
http://download.microsoft.com/downlo..._Framework.chm

The control inheritance hierarchy works the same as the desktop, it's just
that some controls don't support certain events even though they may be
present on the base class.

--
Tim Wilson
..Net Compact Framework MVP

"Myron Marston" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> I've noticed that a number of control events do not fire, even though
> they are defined--such as Button.Paint and Label.Click. I've got a
> couple of questions about this:
>
> 1. How does the control inheritance hierarchy work in the Compact
> Framework? Control (from which Button and Label are derived, according
> to the documentation) fires these events, so if Button and Label are
> derived from Control, the events should be firing, and the On[Event
> Name] methods should be called in derived classes as well. But this
> doesn't seem to be the case.
>
> 2. Is there a list somewhere of defined events that are not raised?
>
> Feel free to point me to an article or another posting answering these
> questions--I searched on here for a while and couldn't find the answers
> to these questions.
>
> Thanks,
> Myron
>

Thanks for the quick response!

> I don't know of a list that states which events are truly supported,
however,
> you may want to look to the class library comparison tool to see if
that
> helps.
>
http://download.microsoft.com/downlo..._Framework.chm

Thanks, this looks to be quite useful. This looks to be like what I'm
looking for--Label.Click and Button.Paint (among others) are greyed
out, indicating they are not supported. But you state that you don't
know of a list that shows what is truly supported--so what is this,
exactly? It looks to be a more accurate listing then what you get from
Visual Studio help. Are there still events this document lists as
supported that are not supported?


> The documentation for events is, well, not very good at this point.
You
> usually determine which events are actually supported just through
trial.
> The control inheritance hierarchy works the same as the desktop, it's
just
> that some controls don't support certain events even though they may
be
> present on the base class.


It really seems like Microsoft dropped the ball on this one. It's
amazing to me that MS would allow these controls to have the event
definitions, but never raise them. Why did Microsoft do it this way?
Considering the fact that these events are defined and raise in the
Control base class, it seems like the derived controls would have to
actively suppress them to get the behavior that we see, doing something
like this:

public class Button : System.Windows.Forms.Control
{
protected override void OnPaint(PaintEventArgs e)
{
// The next line is commented out to suppress the paint event.
// base.OnPaint(e);
}
}

> Thanks, this looks to be quite useful. This looks to be like what I'm
> looking for--Label.Click and Button.Paint (among others) are greyed
> out, indicating they are not supported. But you state that you don't
> know of a list that shows what is truly supported--so what is this,
> exactly? It looks to be a more accurate listing then what you get from
> Visual Studio help. Are there still events this document lists as
> supported that are not supported?
Not sure. The reason why I stated that I didn't know of a list and yet
posted the link to the comparison chm is because I haven't crawled through
the complete chm file to see if it's accurate. While it's probably more
accurate than the docs at this point, there still may be some incorrect
information lurking in there.

> It really seems like Microsoft dropped the ball on this one. It's
> amazing to me that MS would allow these controls to have the event
> definitions, but never raise them. Why did Microsoft do it this way?
> Considering the fact that these events are defined and raise in the
> Control base class, it seems like the derived controls would have to
> actively suppress them to get the behavior that we see, doing something
> like this:
Yep. When deciding "what's in and what's out" in the CF I'm sure that they
had reasons as to why they were not going to support all the events that the
full framework does. As for why the information shows up in intellisense,
this was probably just an oversite. It can be confusing at times. Things
should be better in VS 2005.

--
Tim Wilson
..Net Compact Framework MVP

"Myron Marston" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Thanks for the quick response!
>
> > I don't know of a list that states which events are truly supported,
> however,
> > you may want to look to the class library comparison tool to see if
> that
> > helps.
> >
>
http://download.microsoft.com/downlo..._Framework.chm
>
> Thanks, this looks to be quite useful. This looks to be like what I'm
> looking for--Label.Click and Button.Paint (among others) are greyed
> out, indicating they are not supported. But you state that you don't
> know of a list that shows what is truly supported--so what is this,
> exactly? It looks to be a more accurate listing then what you get from
> Visual Studio help. Are there still events this document lists as
> supported that are not supported?
>
>
> > The documentation for events is, well, not very good at this point.
> You
> > usually determine which events are actually supported just through
> trial.
> > The control inheritance hierarchy works the same as the desktop, it's
> just
> > that some controls don't support certain events even though they may
> be
> > present on the base class.
>
>
> It really seems like Microsoft dropped the ball on this one. It's
> amazing to me that MS would allow these controls to have the event
> definitions, but never raise them. Why did Microsoft do it this way?
> Considering the fact that these events are defined and raise in the
> Control base class, it seems like the derived controls would have to
> actively suppress them to get the behavior that we see, doing something
> like this:
>
> public class Button : System.Windows.Forms.Control
> {
> protected override void OnPaint(PaintEventArgs e)
> {
> // The next line is commented out to suppress the paint event.
> // base.OnPaint(e);
> }
> }
>

Things in VS2005 are much better:
http://www.danielmoth.com/Blog/2005/...or-cf-v20.html

Cheers
Daniel
--
http://www.danielmoth.com/Blog/


"Tim Wilson" <TIM(UNDERSCORE)WILSON(AT)ROGERS(PERIOD)COM> wrote in message
news:(E-Mail Removed)...
>> Thanks, this looks to be quite useful. This looks to be like what I'm
>> looking for--Label.Click and Button.Paint (among others) are greyed
>> out, indicating they are not supported. But you state that you don't
>> know of a list that shows what is truly supported--so what is this,
>> exactly? It looks to be a more accurate listing then what you get from
>> Visual Studio help. Are there still events this document lists as
>> supported that are not supported?
> Not sure. The reason why I stated that I didn't know of a list and yet
> posted the link to the comparison chm is because I haven't crawled through
> the complete chm file to see if it's accurate. While it's probably more
> accurate than the docs at this point, there still may be some incorrect
> information lurking in there.
>
>> It really seems like Microsoft dropped the ball on this one. It's
>> amazing to me that MS would allow these controls to have the event
>> definitions, but never raise them. Why did Microsoft do it this way?
>> Considering the fact that these events are defined and raise in the
>> Control base class, it seems like the derived controls would have to
>> actively suppress them to get the behavior that we see, doing something
>> like this:
> Yep. When deciding "what's in and what's out" in the CF I'm sure that they
> had reasons as to why they were not going to support all the events that
> the
> full framework does. As for why the information shows up in intellisense,
> this was probably just an oversite. It can be confusing at times. Things
> should be better in VS 2005.
>
> --
> Tim Wilson
> .Net Compact Framework MVP
>
> "Myron Marston" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> Thanks for the quick response!
>>
>> > I don't know of a list that states which events are truly supported,
>> however,
>> > you may want to look to the class library comparison tool to see if
>> that
>> > helps.
>> >
>>
> http://download.microsoft.com/downlo..._Framework.chm
>>
>> Thanks, this looks to be quite useful. This looks to be like what I'm
>> looking for--Label.Click and Button.Paint (among others) are greyed
>> out, indicating they are not supported. But you state that you don't
>> know of a list that shows what is truly supported--so what is this,
>> exactly? It looks to be a more accurate listing then what you get from
>> Visual Studio help. Are there still events this document lists as
>> supported that are not supported?
>>
>>
>> > The documentation for events is, well, not very good at this point.
>> You
>> > usually determine which events are actually supported just through
>> trial.
>> > The control inheritance hierarchy works the same as the desktop, it's
>> just
>> > that some controls don't support certain events even though they may
>> be
>> > present on the base class.
>>
>>
>> It really seems like Microsoft dropped the ball on this one. It's
>> amazing to me that MS would allow these controls to have the event
>> definitions, but never raise them. Why did Microsoft do it this way?
>> Considering the fact that these events are defined and raise in the
>> Control base class, it seems like the derived controls would have to
>> actively suppress them to get the behavior that we see, doing something
>> like this:
>>
>> public class Button : System.Windows.Forms.Control
>> {
>> protected override void OnPaint(PaintEventArgs e)
>> {
>> // The next line is commented out to suppress the paint event.
>> // base.OnPaint(e);
>> }
>> }
>>
>
>