[Mono-winforms-list] button implmentation

[Scott Ford]

Since Button, Checkbox, and RadioButton do not declare OnPaint and
ButtonBase does and based on what I have been able to gleam from the
methods that are declared, my guess is that ButtonBase provides methods
for how a generic button has to be drawn and CheckBox and RadioButton
just override the functions that are necessary to obtain the look that
they need. This would make sense if there was a lot of potential
duplicated code among the three classes.

-Scott

-----Original Message-----
From: Mark Gimelfarb [mailto:mark@dawebber.com]=20
Sent: Tuesday, August 12, 2003 1:19 PM
To: Aleksey Ryabchuk
Subject: RE: [Mono-winforms-list] button implmentation

Hello, all!
	I would like to play devil's advocate here (no pun intended), so
I
looked at MS's recommendation in MSDN on drawing owner-drawn controls.
We'll have to assume that Button is in fact an owner-drawn control,
rather
than an inherited control, based on its placement in the inheritance
hierarchy. Control->ButtonBase->Button.

According to this:
http://msdn.microsoft.com/library/default.asp?url=3D/library/en-us/cpguid=
e
/h
tml/cpconrenderingwindowsformscontrol.asp

<quote>
"A control must provide rendering logic by overriding the OnPaint method
that it inherits from Control. OnPaint gets access to a graphics object
and a rectangle to draw in through the Graphics and the ClipRectangle
properties of the PaintEventArgs instance passed to it.

protected virtual void OnPaint(PaintEventArgs pe);

The OnPaint method of the base Control class does not implement any
drawing functionality but merely invokes the event delegates that are
registered with the Paint event. When you override OnPaint, you should
typically invoke the OnPaint method of the base class so that registered
delegates receive the Paint event. However, controls that paint their
entire surface should not invoke the base class's OnPaint, as this
introduces flicker. "

</quote>

So, it seems that MS tells us not to use their own Win32 API to create
owner-
drawn controls (even though I can't prove or state that MS necessarily
follows
their own preachings), but to use GDI+ facilities to do the drawing of
the=20
control.=20

Maybe it will be easier to implement our own control drawing routines,
in order=20
to be:
a) compatible with MS
b) more platform (and P/Invoke) independent.

Just some thoughts on the topic.

Regards,
		Mark.


-----Original Message-----
From: mono-winforms-list-admin@lists.ximian.com
[mailto:mono-winforms-list-admin@lists.ximian.com] On Behalf Of Aleksey
Ryabchuk
Sent: Tuesday, August 12, 2003 3:26 AM
To: mono-winforms-list@lists.ximian.com
Subject: RE: [Mono-winforms-list] button implmentation

Hello,

I agree that we should delegate as much work as
possible to Wine. But all button controls ( Button,
CheckBox, RadioButton) in SWF have to be ownerdrawn,
because they implement a number of properties not
supported by Win API. For example, TextAlignment can
only be left, center or right in WinAPI, while in SWF
it can be TopLeft or RightBottom etc. The same is for
Label control.

Another problem is that the patched version of Wine is
not able to draw some controls at all. CheckBox,
RadioButton and ComboBox are among them.=20

Regards
Aleksey


--- Dennis Hayes <DENNISH@Raytek.com> wrote:
>=20
> Just thought I'd poke my head in on this and point
> out that the Windows
> implementations usually don't actually draw
> themselves. They simply wrap up
> a win32 HWND and allow the system to draw the
> control.
>=20
> This is what we should do as well. That is why we
> use Wine.
> Dennis
>=20
>=20
>=20
>=20
> -----Original Message-----
> From: Jonathan Gilbert
> [mailto:2a5gjx302@sneakemail.com]=20
> Sent: Tuesday, August 12, 2003 2:41 AM
> To: mono-winforms-list@lists.ximian.com
> Subject: RE: [Mono-winforms-list] button
> implmentation
>=20
> Just thought I'd poke my head in on this and point
> out that the Windows
> implementations usually don't actually draw
> themselves. They simply wrap up
> a win32 HWND and allow the system to draw the
> control.
>=20
> The other thing to point out is that Microsoft codes
> in this pattern:
>=20
> public event PaintEventHandler Paint;
>=20
> protected void OnPaint(PaintEventArgs e)
> {
>   if (Paint !=3D null)
>     Paint(this, e);
> }
>=20
> Therefore, it is likely that a subclass would hook
> the 'Paint' event
> instead of overriding the 'OnPaint' method.
>=20
> Jonathan
>=20
> At 11:09 AM 11/08/2003 -0700, you wrote:
> >OK let's leave it where it is for the time being.
> >Actually I am wrong twice; the spec says OnPaint
> for Button is inherited
> >from control.
> >How can control handle OnPaint for Button?
> >Am I missing something here?
> >Anyway, there are several thousand signature errors
> for me to fix before I
> >come back to this one.
> >Dennis
> >
> >-----Original Message-----
> >From: Aleksey Ryabchuk [mailto:ryabchuk@yahoo.com]=20
> >Sent: Monday, August 11, 2003 7:11 AM
> >To: mono-winforms-list@lists.ximian.com
> >Subject: Re: [Mono-winforms-list] button
> implmentation
> >
> >Hello,
> >
> >May be from technical point of view there is no
> >difference where this code is located . But it can
> be
> >wrong logically, because this code is not common
> for
> >all button controls.
> >
> >Aleksey
> >
> >--- Dennis Hayes <denisraytek@yahoo.com> wrote:
> >> Button.cs implments OnPaint.
> >> The spec says this should be in ButtonBase.cs.
> >> ButtonBase is just
> >> base.OnPaint (pevent)
> >> There is a lot of implmentation in button.cs
> >> =20
> >> *
> >> It looks like just replacing the ButtonBase
> OnPaint
> >> with the Button OnPaint, and removing the OnPaint
> >> from Button.cs would be the correct option.
> >> *
> >> Can someone do this and verify that is does not
> >> break any of the test?
> >> Thanks,
> >> Dennis

_______________________________________________
Mono-winforms-list maillist  -  Mono-winforms-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list