Subclassing a ComboBox

[John R. Heathcote]

While I was reviewing the Windows messages in a Subclassed ComboBox I noticed that the %WM_KEYUP message is not sent to the ListBox portion of the Combo control, but %WM_KEYUP is sent to the edit control as expected. One can use the Up, Down, Page Up, and Page Down keys to navigate the list when the drop down ListBox is exposed, so there is a Key Up condition and I would assume a %WM_KEYUP message as well.

Just wondered why the apparent discrepancy?

[Jeff Blakeney]

Because it is Windows and discrepancies are the norm.

[Edwin Knoppert]

This window never get's the focus, it looks so but is not.

[Michael Mattias]

I'd guess it wants keyDOWN rather than keyUP because if you hold the key down and it starts to repeat, the control is supposed to move to the next item.

I suppose you could try holding a key down... let me try it right here, I have an app handy...yes, if you hold the up/down arrow keys down, you start scrolling. (CBS_DROPDOWNLIST).


MCM

[John R. Heathcote]

Edwin,

This window never get's the focus, it looks so but is not.

Yeah, after looking closer at the ComboBox control I kinda figured that. Still, it's that consistency thing you know.

MCM

Yes, I know when you hold an arrow key down the listbox scrolls. What I'm trying to do is to figure out what specific Windows messages are sent to the Edit and ListBox portion of the ComboBox control so I can fire specific procedures for specific messages. When those specific messages such as %WM_KEYUP and %WM_CHAR are not sent to the ListBox makes it a little more difficult to trap the proper Windows message at the proper time. It looks like I will have to track when the ListBox is dropped/closed from the Edit control, plus the specific key pressed, and proceed accordingly.

[Michael Mattias]

of the ComboBox control so I can fire specific procedures for specific messages. When those specific messages such as %WM_KEYUP and %WM_CHAR are not sent

Not to belabor the obvious but.... if a control does not send a notification you need for your application, maybe you should pick a different standard control or write your own control.

In this case, the word "superclass" comes to mind....nay, it LEAPS to mind....

[John R. Heathcote]

In this case, the word "superclass" comes to mind....nay, it LEAPS to mind....

Yes, I thought about creating a superclass control too, if I only knew how to do it, but I don't, plus there aren't too many superclass examples available that go into the necessary depth for something like this. Hence my request for "superclass" examples in the "You Talk PowerBASIC Listens" forum.

That said, so far the ComboBox is the only control I'm having difficulty with, the other standard controls are pretty straightforward and are relatively easy to work with by comparison.

[Michael Mattias]

>plus there aren't too many superclass examples available

Well, now it's not too many minus one.

The basic idea is, "it acts like a <button here, but anything> except for <something>.

This button superclass is just like a regular button, except it processes the <enter> key just like the spacebar key and effects an "I was clicked"

Once the class is registered , you can use it anywhere you would use any of the 'standard' window classes, in either a ....

   hCtrl = CreateWindowEx  ( exstyle, [b]szclassname[/b] .....)

...call if you are SDK'ing, or in a ....

   CONTROL ADD  $CLASSNAME_TSIBUTTON .....

.. statement if you are DDT'ing

' -----------------------------------------------------'
' SET UP BUTTONS WHICH WILL "click me" on <ENTER> and
' advance-retreat in tab order on Tab/Shift Tab
' assumes: Buttons are NOT using the GLW_USER bytes
' -----------------------------------------------------'

$CLASSNAME_TSIBUTTON  = "TSI_837API_buttonclass"    ' try this

'$CLASSNAME_TSIBUTTON  = "TSI_Button_One_class"
%PWM_BUTTON_ONE_INIT  = %WM_USER + 1&

#IF 1
FUNCTION UnRegisterTsiButtonClass ()  AS LONG

 LOCAL szClass AS ASCIIZ * %MAX_PATH

 szClass           = $CLASSNAME_TSIBUTTON
 UnregisterCLass     szClass, GetModuleHandle (BYVAL %NULL) ' assumes class was registered by this application.

END FUNCTION



FUNCTION RegisterTsiButtonClass ()  AS LONG

 LOCAL szClass AS ASCIIZ * %MAX_PATH

 LOCAL WCE AS WndClassEx, iRet AS LONG, hInst AS LONG
 LOCAL OldWndProc  AS DWORD
 ' to create a dummy Window

 hInst    = GetModuleHandle (BYVAL %NULL)    ' for this program only
 szClass  = "button"      ' get the base class name


 WCE.CbSize                    =   SIZEOF(WCE)                         ' must set first
 iRet                          =   GetClassinfoEx (hInst, szClass, WCE)   ' get button class info into WCE
 IF ISTRUE iRet  THEN    ' succesfully retrieved button class info

      ' MSGBOX "Button class cbWndExtra in=" & FORMAT$ (WCE.cbWndExtra)
      ' YES THIS WAS PROBABLY MY PROBLEM. THE BUTTON CLASS RETURNS '8' FOR THIS VALUE AND I WAS SETTING TO ZERO
      OldWndPRoc               =   WCE.lpfnWndProc          ' we need this later...
     ' change what's going to be different
      szClass                  = $CLASSNAME_TSIBUTTON
      WCE.lpszClassname        = VARPTR (szClass)
      WCE.lpfnWndProc          = CODEPTR(WndProc_TSI_BUTTON_ONE_PROC)
      WCE.hInstance            = hInst
      ' we want the %CS_GLOBAL Class so DLLs attached to this program can use the class
      ' 1.11.06 I do not need this, either in this application, leave it alone
      'WCE.style                = (WCE.style OR %CS_GLOBALCLASS
      ' 1.11.06 I wonder if this extra was in use and did not add that!
      ' SDK:
      '   The application can add to both the extra class bytes and the extra window bytes because it is registering a new class. The application must follow two rules when doing this: (1) the original extra bytes for both the class and the
     '    window must not be touched by the superclass for the same reasons that an instance subclass or a global subclass should not touch these extra bytes; (2) if the application adds extra bytes to either the class or the window instance
     '   for the application's own use, it must always reference these extra bytes relative to the number of extra bytes used by the original base class. Because the number of bytes used by the base class may be different from one version of
      '  the base class to the next, the starting offset for the superclass's own extra bytes is also different from one version of the base class to the next.
    ' --- BAD LINE IN Versions up to 1.2.2
    '  WCE.cbWndExtra           = 0&
      ' YES THIS WAS PROBABLY MY PROBLEM. THE BUTTON CLASS RETURNS '8' FOR THIS VALUE AND I WAS SETTING TO ZERO
      ' I SHOULD HAVE LEFT IT ALONE!
    ' -----


      ' and register the new class
      iRet   = RegisterClassEx (WCE)
      IF ISTRUE iret THEN    ' registration succeeded
              ' call the window procedure with 'special' message value
              ' which means "we just registered the class and the new WndProc should
              ' store the oldWndProc in its STATIC variable
              CALL WndProc_TSI_BUTTON_ONE_PROC (%NULL, %PWM_BUTTON_ONE_INIT, %NULL, OldWndProc)
      ELSE
           MSGBOX "Could Not Register new class"
      END IF
  ELSE
      MSGBOX "Could not get button class info"
  END IF


END FUNCTION

FUNCTION WndProc_TSI_BUTTON_ONE_PROC (BYVAL hWnd AS LONG, BYVAL uMsg AS LONG, BYVAL wParam AS LONG, BYVAL lpAram AS LONG) AS LONG

  STATIC OldWndProc AS LONG
  LOCAL   CtrlId AS LONG, keyState AS LONG


     SELECT CASE AS LONG uMsg

          CASE  %PWM_BUTTON_ONE_INIT    ' artificial call
              OldWndProc   = lparam
              EXIT FUNCTION  ' DO NOT PASS TO OLD WNDPROC, BECAUSE THIS CALL IS ARTIFICIAL!!!


          '%CASE %WM_CREATE
           ' nothing in particular I need to do here
           ' if I do not callWindowPRoc, the button remains drawn in "down" state.. try calling

             ' convert <Enter> into click on this control, and Tab into focus changes and exit!
          CASE  %WM_CHAR
            IF wParam = %VK_RETURN OR %WM_CHAR = %VK_SPACE THEN  ' treat as a click...and post WM_COMMAND, BN_CLICKED to parent:
                 ctrlId    = GetDlgCtrlId (hWnd)
                 PostMessage GetParent(hWnd), %WM_COMMAND, MAKDWD(CtrlId,%BN_CLICKED), GetDlgItem(hWnd,Ctrlid)

                 ' we still have to call the original window proc.. 6/25/05 or do I?
                 ' I really shouldn't on space, because that will generate an additional click..
                 ' 6.25.05 Exited function and will run a while to see what happends
                 FUNCTION  = 0
                 EXIT FUNCTION
             ELSEIF wParam = %VK_TAB THEN
                     ' < 0 assumes GetKeyState returns a LONG... should change to support DWORD DECLARES
                       KeyState  = GetKeyState(%VK_SHIFT)
                       SetFocus    GetNextDlgTabItem (GetParent(hWnd),  hWnd, BIT(keyState, 31))
                      ' next works OK but suffers the LONG/DWORD problem
                      'SetFocus GetNextDlgTabItem (GetParent(hWnd), hWnd, GetKeyState(%VK_SHIFT) < 0)
                      FUNCTION = 0
                     ' EXIT FUNCTION
                     ' 6.25.05 Exit the function because the default proc does nothing with TAB anyway
                     EXIT FUNCTION
            END IF

         ' CASE ELSE
         ' nothing to do but allow the original WndPRoc to be called

       END SELECT
     ' if we get here, we just call the original Window procedure and let processing happen..
      FUNCTION =  CallWindowProc (OldwndProc, hWnd, uMsg, wParam, lparam)



END FUNCTION
#ENDIF

You're stuck with - or perhaps blessed with - my notes to myself re how I had this screwed up for the longest time because I did not respect the "extra bytes" in the base class.

Hence my request for "superclass" examples in the "You Talk PowerBASIC Listens" forum.

Just one man's opinion, but you will get much better examples from members than from the factory. And frankly you will get A) better examples than this and no doubt B) one or more folks pointing out all the mistakes I made in this example.


MCM

[Michael Mattias]

And just as one more option....

I recently did an application where I wanted to subclass a combobox... or so I at first thought.

Turns out what I really wanted to do was subclass the EDIT control which is part of the two-part (edit and list) combobox control. You can use the CB_GETCOMBOBOXINFO message to get a handle to the edit control, which you can then subclass.

Maybe that's the approach you need here to "find" all the messages.... subclass BOTH the edit and list portions of the combobox control ?????

[John R. Heathcote]

MCM,

Thanks for the example, will take a closer look at it when I have the time.

You're stuck with - or perhaps blessed with - my notes to myself re how I had this screwed up for the longest time because I did not respect the "extra bytes" in the base class.

You can't have too much code documentation I always say, besides comments serve to give a not so gentle reminder to yourself of what you did, but also the intent behind your code. Believe it or not I find your "notes" a valuable resource.

Just one man's opinion, but you will get much better examples from members than from the factory. And frankly you will get A) better examples than this and no doubt B) one or more folks pointing out all the mistakes I made in this example.

I don't disagree, but I think if you were to take inventory of the number of existing subclass vs. superclass examples available in the forums, POFFS, etc., you would find that subclass far out number superclass examples. At this point I will look at a superclass example wherever it comes from, beggars can't be choosers.

Turns out what I really wanted to do was subclass the EDIT control which is part of the two-part (edit and list) combobox control. You can use the CB_GETCOMBOBOXINFO message to get a handle to the edit control, which you can then subclass.

Maybe that's the approach you need here to "find" all the messages.... subclass BOTH the edit and list portions of the combobox control ?????

Yes, that is essentially what I did, but when I did so that's when I discovered the ListBox control did not support the %WM_KEYUP and %WM_CHAR messages despite the key up condition when navigating the list and the fact you can select a ListBox item with 'Enter', whereas the Edit control did support these messages. Consistency?

The key was to keep track when the ListBox was visible and when it was closed from the Edit control, easy enough with the %CBN_DROPDOWN and the %CBN_CLOSEUP notifications. If the ListBox was visible I assumed it had "input focus" and the key press intercepted in the Edit subclass was forwarded to the ListBox subclass procedure. This allowed me to use the Up/Down arrow navigation keys, and also allowed me to make a ListBox selection by pressing 'Enter'. I know my assumption is a trade off, but my ComboBox subclassing works well enough now and does pretty much what I want it to do.

[Michael Mattias]

....take inventory of the number of existing subclass vs. superclass examples available .... subclass far out number superclass

Accepting guesses? The same reason I created superclass above.

It's essentially the same coding of the procedure (the subclass proc and the superclass proc), but if you have 'many' of the same controls, it's easier to just create the superclass and use those controls than to individually subclass each 'button' or whatever control. (well, not really, it just seems that way).

Combine this with that we see lots more "demos" of , "What is the easiest way...?" versus "What is the best way...?" and you have a match made in... well, one of the nether worlds.

MCM