Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!uunet!microsoft!kensy
From: kensy@microsoft.UUCP (Ken SYKES)
Newsgroups: comp.windows.ms.programmer
Subject: Re: Return key in combo boxes.
Message-ID: <59926@microsoft.UUCP>
Date: 19 Dec 90 00:01:32 GMT
References: <1990Dec6.144321.12168@jarvis.csri.toronto.edu> <28660006@hpopd.HP.COM>
Reply-To: kensy@microsoft.UUCP (Ken SYKES)
Organization: Microsoft Corp., Redmond WA
Lines: 31

In article <28660006@hpopd.HP.COM> richardh@hpopd.HP.COM (Richard Hancock) writes:
>/ hpopd:comp.windows.ms.programmer / eric@eecg.toronto.edu (Eric Smith) /  7:43 pm  Dec  6, 1990 /
>
>> Moreover, the Guide to Programming explicitly warns
>> against subclassing predefined window classes (i.e. combo boxes),
>> so messages can't be intercepted there either.
>
>I've been subclassing edit controls for years (with no ill effects).
>
>Richard.

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.  This has several implications such as:

	- What about the controls that already existed?  Do I go and set all
          of their window procedures or leave them alone?
	- Am I going to stick around until all of the controls have been
	  destroyed or will I run through again and point to the old Window
	  procedures?
	- And probably most important, do I have the right to change the
	  behavior of ALL the apps running in the system?  Most of the time
	  the answer is no.

It is for this reason and possibly others that predefined CLASSES shouldn't
be subclassed.

Ken Sykes
Disclaimer: The above opinions are solely my own.