Superclassing Common Controls

[BOB MECHLER]

In controls where messages are sent as %WM_NOTIFY can they be superclassed and if so, are the same variables used to extract the hdr.code.

Also are there any caveats to superclassing. Do they go out of scope when the program ends or need they be destroyed in the %WM_DESTROY event.

Bob Mechler

[Michael Mattias]

WM_NOTIFY is unaffected by either superclassing or subclassing, as is not sent to the control, it is sent to the owner of the control.

Speaketh SDK:

WM_NOTIFY Message

--------------------------------------------------------------------------------

The WM_NOTIFY message is sent by a common control to its parent window when an event has occurred or the control requires some information.

What is it you want to do with what control? Subclassing and/or superclassing may be total overkill, as the Common (capital C) Controls send a lot more notification messages ("opportunities") than do common (small c) controls.

MCM

[Jules Marchildon]

Q1: In controls where messages are sent as %WM_NOTIFY can they be superclassed
A1: Yes

Q2: and if so, are the same variables used to extract the hdr.code.
A2: Yes

Q3: Also are there any caveats to superclassing.
A3: same as subclassing, need to handle instance data correctly if multple instances, superclassing gives you wm_create wm_nccreate messages, and lastly pointed out by Dominic Mitchell, be aware when forming superclass or subclass chains.

Q4: Do they go out of scope when the program ends or need they be destroyed in the %WM_DESTROY event.
A4: Yes, when program ends. From Win32Api Help file: "All window classes that an application registers are unregistered when it terminates."

[BOB MECHLER]

My goal is to build a toolbox of ready made, application/program specific controls where just CONTROL ADD "NCusip" etc will do all the work of filtering of keystrokes allowed and providing in the callback a lookup to another file with it's own lookup window. I hope this can be done by simply calling a function that already does this and return the value to the super class procedure. Currently I have to place another control on the screen and show it when the field is active and hide it when it's not.

For common controls like ListView,TreeView and Tab I tried looking in Poffs on how to handle the WM_Notify events. I guess I could create a popup style dialog the exact size of the common control and do my work there. If I make is a child window, I think it can be tabbed into but I'm not sure where it will go when I exit. A simple sample is needed or just verify that there is something in Poffs or the Forum and I'll continue to hunt.

Instead of hunting by topic I may just look for posts by the names of people whose code has proven to do various jobs well and I can understand it.

Thanks,

Bob Mechler

[Chris Holbrook]

Bob, looking back through the forum it looks as if you have been chasing this one down for years! Had you considered using message cracker type of approach? As in James Fuller's post #11 on this thread:http://www.powerbasic.com/support/pbforums/showthread.php?t=36073&highlight=classless

[Michael Mattias]

I have done this kind of thing for years... making a 'child control' which is actually a full-blown window with its own child windows.

If you want a practical example of doing this... take a look at MDI applications. The "child controls" of the frame window are full-blown windows, each with their own window procedure.


MCM

[BOB MECHLER]

Both reasonable suggestions for future study but seems to be overkill for what I want. JC Fuller's code is over my head as are the MDI code.

Just need an example of a superclassed ListView where I can trap some keystrokes and columnclicks that normally are accessible during the dialog callback. I tried using the CALL listviewcb as I added the control approach but it ignored the WM_NOTIFY messages.

I probably just haven't looked hard enough.

Thanks,

Bob Mechler

[Michael Mattias]

As I said before... WM_NOTIFY is sent to the PARENT of the listview, not the listview itself. Superclassing does nothing and in any case not necessary to get clicks and keys.

All the keystrokes and clicks ARE accessible in the dialog callback procedure:

WM_NOTIFY/NM_CLICK
WM_NOTIFY/NM_DBLCLK
WM_NOTIFY/LVN_KEYDOWN
WM_NOTIFY/NM_CHAR
WM_NOTIFY/NM_RCLICK

(There is no 'Key up' notification available from listview)

DDT "CONTROL ADD... CALL" procedure is only called on WM_COMMAND... which listview does not send to anything. So you will have to pick up WM_NOTIFY in the owner procedure.

Or, don't use a listview control. Listviews normally don't process any keystrokes except up-down and left-right arrows anyway.

It really sounds like you are trying to do something the long way.

[BOB MECHLER]

LOCAL kp AS LV_KEYDOWN PTR
see kp below. I just needed the up arrow actually.

      CASE %WM_NOTIFY
        SELECT CASE CBCTL
          CASE %IDM_LISTVIEW
             CONTROL HANDLE CBHNDL, %IDM_LISTVIEW TO hctrl&
             my_LpLvNm = CBLPARAM
             SELECT CASE @my_LpLvNm.hdr.code
               CASE %NM_DBLCLK
                 I = ListView_GetNextItem(BYVAL hctrl&, -1, %LVNI_SELECTED)
                 IF I > -1 THEN
                   VKEY = 20
                   GETKEY = -1
                 END IF
               CASE %NM_CLICK
                 I = ListView_GetNextItem(BYVAL hctrl&, -1, %LVNI_SELECTED)
                 IF I > -1 THEN
                   GETKEY = -1
                 END IF
               CASE %LVN_COLUMNCLICK
                 LV_COLUMNID = @my_LpLvNm.iSubItem
                 VKEY = 21
               'CASE ELSE
                ' VKEY = 22
             END SELECT
             kp = CBLPARAM
             SELECT CASE @kp.hdr.code
               CASE %LVN_KEYDOWN
                 SELECT CASE @kp.wVKEY
                   CASE %VK_DOWN
                     GETKEY = -1 'needed to refresh hot fields when not at bottom
                   CASE %VK_UP
                     GETKEY = -1 'needed to refresh hot fields when not at top
                 END SELECT
             END SELECT
        END SELECT
        FUNCTION = 0: EXIT FUNCTION

[Michael Mattias]

WM_NOTIFY wParam :

Parameters

[wparam] idCtrl
Identifier of the common control sending the message. This identifier is not guaranteed to be unique. An application should use the hwndFrom or idFrom member of the NMHDR structure (passed as the lParam parameter) to identify the control.

I have no idea how CBCTL is correct in this code. On WM_COMMAND it's LOWRD(wParam) but that is not ALWAYS true on WM_NOTIFY (as documened by Microsoft, above).


Using DDT I think I would...

CASE %WM_NOTIFY
         my_LpLvNm = CBLPARAM
        IF @my_lplvmn.hdr.idFrom = %IDM_LISTVIEW THEN 
              hCtrl = @my_lplvmn.hdr.hWndfrom 
             ......

[Chris Holbrook]

I have no idea how CBCTL is correct in this code.

PB help system says:

Therefore, CBCTL is functionally equivalent to LO(WORD, wParam&) in a conventional Callback Function, and equivalent to LO(WORD, CBWPARAM) in a DDT Callback Function

[Michael Mattias]

Yes, that is what CBCTL is all right... the problem is, on WM_NOTIFY LOWRD(wparam) is not guaranteed to be the identifier of the sending control!

[BOB MECHLER]

LOCAL my_LpLvNm AS NM_LISTVIEW PTR
is what I used for the notification messages.

Thanks though for pointing out the code changes that would be more reliable. In the past I always used the same id for the listview, something I'm getting away from now. The code was taken directly from an example and has never falied, not saying in a more involved program it might not.

Bob Mechler

[Michael Mattias]

>The code was taken directly from an example ..

Old code never dies, it just gets cut to the clipboard.