Defined Control Events that do not fire

[Myron Marston]

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

 

[Tim Wilson]

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/downl...4-8ddb-577720a32e5d/NET_Compact_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.

 

[Myron Marston]

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/downl...4-8ddb-577720a32e5d/NET_Compact_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);
}
}

 

[Tim Wilson]

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.

 

[Daniel Moth]

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

Cheers
Daniel