[Mono-winforms-list] button implmentation
Dennis Hayes
DENNISH@Raytek.com
Tue, 12 Aug 2003 11:22:54 -0700
The .NET spec says that Button inherits the OnPaint from Control.
Winchurn, a .dll compare routine, verifies that the binary matches the spec.
Maybe Button registers an "internal" method with the control onPaint?
Can Button have an "new internal OnPaint" that hides the Control OnPaint,
but that is not visible outside the .dll?
No, that will not work, because Button must expose the OnPaint from Control.
*
To be 100% compatible with MS, Button must expose only the OnPaint inherited
from Control.
*
How? I do not know.
Important? Not very. I would rather have Button work and expose its own
OnPaint than have it use OnPaint from Control and not work.
I am going to work on some of the other 3,000 signature errors that are easy
to fix.
Also in control, OnWmCommand should be marked as internal, not protected,
unless it needs to be accessed outside of the SWF dll.
This is true of any method/property that is not part of the spec.
Dennis
-----Original Message-----
From: Mark Gimelfarb [mailto:mark@dawebber.com]
Sent: Tuesday, August 12, 2003 10:19 AM
To: mono-winforms-list@lists.ximian.com
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=/library/en-us/cpguide/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
control.
Maybe it will be easier to implement our own control drawing routines, in
order
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.
Regards
Aleksey
--- Dennis Hayes <DENNISH@Raytek.com> wrote:
>
> 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.
>
> This is what we should do as well. That is why we
> use Wine.
> Dennis
>
>
>
>
> -----Original Message-----
> From: Jonathan Gilbert
> [mailto:2a5gjx302@sneakemail.com]
> Sent: Tuesday, August 12, 2003 2:41 AM
> To: mono-winforms-list@lists.ximian.com
> Subject: RE: [Mono-winforms-list] button
> implmentation
>
> 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.
>
> The other thing to point out is that Microsoft codes
> in this pattern:
>
> public event PaintEventHandler Paint;
>
> protected void OnPaint(PaintEventArgs e)
> {
> if (Paint != null)
> Paint(this, e);
> }
>
> Therefore, it is likely that a subclass would hook
> the 'Paint' event
> instead of overriding the 'OnPaint' method.
>
> Jonathan
>
> 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]
> >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
> >>
> >> *
> >> 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