[comp.windows.ms.programmer] Return key in combo boxes.

eric@eecg.toronto.edu (Eric Smith) (12/07/90)

Perhaps someone on the net has a solution or suggestion for the
following problem:

I am trying to set up WinWord-like combo boxes (with CBS_DROPDOWN
| CBS_HASSTRINGS) to allow users to select fonts and sizes from
the list part of the combo, or type them into the edit part.

All is well, except that I want the return key to work the same
way it does in WinWord, namely, it puts the current selection
into the associated edit box, and undrops (hides) the list.  In
my application, typing return when the combo box has focus only
causes a system beep--no notification message or anything.  Of
course, when the combo box has focus the main window proc
receives no keyboard messages, so there's nothing to intercept at
that point.  Moreover, the Guide to Programming explicitly warns
against subclassing predefined window classes (i.e. combo boxes),
so messages can't be intercepted there either.

Obviously since WinWord does it, it could be done, although I
expect WinWord was written with the 2.0 API, so the authors
probably used separate list box and edit box controls.  One
solution might be to use SetWindowsHook, but even if I could get
that to work, it seems like overkill for such a simple problem.

Thank you in advance for your help,

Eric Smith

Generic Design Systems Corporation	(416) 236-0908
1199 Islington Ave.			eric@eecg.toronto.edu	
Etobicoke, Ont.				CompuServe:  72371,3015
M8Z 4T2					GEnie:  E.SMITH29

richardh@hpopd.HP.COM (Richard Hancock) (12/07/90)

/ 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.

eric@eecg.toronto.edu (Eric Smith) (12/08/90)

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.

Hmmm.  In that case, does anyone know why the Guide warns against
this practice?  Has anyone experienced problems with using this
approach in Win3?  It certainly seems like the most direct way to
solve this sort of problem.

Eric Smith

Generic Design Systems Corporation	(416) 236-0908
1199 Islington Ave.			eric@eecg.toronto.edu	
Etobicoke, Ont.				CompuServe:  72371,3015
M8Z 4T2					GEnie:  E.SMITH29

spolsky-joel@cs.yale.edu (Joel Spolsky) (12/09/90)

In article <1990Dec7.235148.11968@jarvis.csri.toronto.edu> eric@eecg.toronto.edu (Eric Smith) writes:
>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),
>>
>>I've been subclassing edit controls for years (with no ill effects).
>
>Hmmm.  In that case, does anyone know why the Guide warns against
>this practice? 


While it may work in Win3, Microsoft probably does not want to commit
to making it work in Win4, or OS/2 2.0, or other futuristic
platforms... 

Joel Spolsky
spolsky@cs.yale.edu
--
#define GlobalLock(x) x
#define GlobalUnlock(x)               
	-from the MS Windows 5.0 windows.h
NEVER use handles returned from GlobalMalloc as pointers!
	-bold print, page 1, MS Window 5.0 SDK documentation


	

kensy@microsoft.UUCP (Ken SYKES) (12/19/90)

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.

fjb@dhw68k.cts.com (Frank Bielsik) (12/20/90)

.
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