Drawing a 3D Push Button

Mike Bryga -- MBryga@PickSys.com
Thursday, January 23, 1997

Environment: MSVC 4.0, Win 95/NT 4.0

I've subclassed a Button of the Push Button personality control using =
AppWizard and am having difficulty getting it to look like Microsoft's =
Push Button in VB4.0a.

Microsoft's Push Button appears to ignore the Appearance property both =
at design time and runtime - changing it from Flat to 3-D has no effect. =
The button is normally raised, and when pushed appears to be flush with =
the form's surface. That is what I want.

At design time, my subclassed control appears flat if (m_sAppearance =
=3D=3D 0) and sunken like an Edit Box if (m_sAppearance =3D=3D 1). This =
is not what I want. I do nothing at design time, but call FillRect() in =
OnDraw() to achieve this (undesired) behaviour. What do I want to do at =
design time?

At runtime, my subclassed control normally appears raised if =
(m_sAppearance =3D=3D 0) - great, and appears raised but set in a sunken =
Edit Box if (m_sAppearance =3D=3D 1) - so so. When clicked, both press =
through the level of the form and appear sunken - yuch. I do nothing but =
rely on the stock m_sAppearance property and DoSuperclassPaint() in =
OnDraw(). What do I want to do at runtime?

I'm also confused by why AppWizard overrides OnDraw() and calls =
DoSuperclassPaint() instead of the the OnDraw(). Looking at the on-line =
documentation for COleControl::OnDraw(), it would appear to make sense =
to call it. Can someone explain this discrepancy to me?

Thanks again, Mike.

---

Joao Marcos Melo Mendes -- jmmm@megamedia.pt
Monday, January 27, 1997

Hello, :)

On Thu, 23 Jan 1997, Mike Bryga wrote:

Environment: MSVC 4.0, Win 95/NT 4.0

> I'm also confused by why AppWizard overrides OnDraw() and calls 
> DoSuperclassPaint() instead of the the OnDraw(). Looking at the on-line 
> documentation for COleControl::OnDraw(), it would appear to make sense 
> to call it. Can someone explain this discrepancy to me?

Yes, but if you look at the code for COleControl::OnDraw(), you'll see... 
no code. The funtion is just there to be overriden by the derived class. 
The thing is, C++ class derivation and OLE Control subclassing aren't the 
same thing at all.
For instance, in an OCX project I'm developping, I have class A derived 
from COleControl and class B derived from class A. However, class A is not 
a subclassed control at all, while class B subclasses a BUTTON.
If you look at the implementation for COleControl::DoSuperClassPaint, 
you'll see that it looks for a subclassed window class and sends that 
class's WindowProc the WM_PAINT (or WM_PRINT) message.
It certainly makes more sense for the default implementation of a 
subclassed window's paint routine to be its superclass's paint than its 
C++ derived class's paint.

I hope I made some sense there...:)

                                        Joao Mendes
                                        MegaMedia, S.A.

"We're fools to make war on our brothers in arms." - Mark Knopfler

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2

mQBNAzKu3TgAAAECAL8+YSEFZ0XrlBMu9t2xDq3rhpWZoscP83VrX5MevAm3UOd6
fOtDKsJxsWugnVMexo50NfBjeWOHz5nA1b9hYx0ABRG0H0pvYW8gTWVuZGVzIDxq
bW1tQG1lZ2FtZWRpYS5wdD4=
=sspP
-----END PGP PUBLIC KEY BLOCK-----

---

| Вернуться в корень Архива |