Path: utzoo!attcan!telly!lethe!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!zardoz.cpd.com!dhw68k!fjb
From: fjb@dhw68k.cts.com (Frank Bielsik)
Newsgroups: comp.windows.ms.programmer
Subject: Re: Return key in combo boxes.
Summary: should you subclass?
Keywords: subclass superclass
Message-ID: <1990Dec19.202010.22133@dhw68k.cts.com>
Date: 19 Dec 90 20:20:10 GMT
References: <1990Dec6.144321.12168@jarvis.csri.toronto.edu> <28660006@hpopd.HP.COM> <59926@microsoft.UUCP>
Distribution: all
Organization: Wolfskill & Dowling residence; Anaheim, CA (USA)
Lines: 31

.
In article <59926@microsoft.UUCP> kensy@microsoft.UUCP (Ken SYKES) writes:
>There's a difference between subclassing a window CLASS and a window CONTROL.
>It is okay to subclass a window CONTROL because it is only one instance and
>the control usually belongs to you.  Subclassing a predefined window CLASS
>changes the behavior of ALL controls created after the class has been
>subclassed.
>...
>It is for this reason and possibly others that predefined CLASSES shouldn't
>be subclassed.
.
The Reference Manual -- Volume 1 from the SDK also gave me the impression
that it WAS talking about subclassing windows (not classes).
(Maybe an error? Doesn't matter, I'm subclassing windows anyway!)
.
From 1.2.10 Window Subclassing (page 1-17):
        NOTE:  An application should not attempt to create a window subclass
               for standard Windows controls such as combo boxes and buttons.
.
From Chapter 4 SetWindowLong entry (page 4-416):
        An application should not attempt to create a window for standard
        Windows controls such as combo boxes and buttons.
.
For people who wanted to subclass all instances of a class in their
application only, there was a method described on MS Online a year
or two ago called "superclassing" -- create your own class (like
"mycombobox"), and copy all the info from the standard "combobox"
class to it (except your specialized wndproc).
.
Frank Bielsik
fjb@dhw68k.cts.com