Defined Control Events that do not fire

  • Thread starter Thread starter Myron Marston
  • Start date Start date
M

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
 
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.
 
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.
Click to expand...
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.
Click to expand...


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?
Click to expand...
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:
Click to expand...
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.
 
Back
Top