DIALOG CALLBACK question.

[BOB MECHLER]

I'd like to create various versions of controls that send their messages to the WM_NOTIFY event. I know that an individual control can reference it's own callback but generally only the WM_COMMAND level messages are passed there.

The code below from an old calendar example by Borge is giving me an idea that many of you probably figured out a long time ago.

The calendar control specifically calls the same dialog procedure as the one specified for the dialog.

Is it possible to just as easily call a dialog procedure that is attached to any number of other hidden dialogs and their dialog procedures to process the WM_NOTIFY events for variations of listviews,treeviews and/or calendar controls?

The reason is to keep the WM_NOTIFY small and manageable and related to just one version of the control.

    CONTROL ADD "SysMonthCal32", hDlg, %ID_CALENDAR, "", 6, 26, 340, 190, %WS_CHILD OR _
                %WS_TABSTOP OR %WS_VISIBLE, %WS_EX_CLIENTEDGE CALL DlgCallback
    'See Commctrl.inc for other useful Constants and Type structures

    DIALOG SHOW MODAL hDlg CALL DlgCallback

BOB MECHLER

[Michael Mattias]

The DDT "CALL" procedure named in the CONTROL ADD statement is only called on WM_COMMAND.. plainly documented.

If you want a procedure called on other notification messages===> new feature suggestion.

As far as handling WM_NOTIFY in the owner procedure... I assume the 'unwieldy manageability' inherent in the lparam (CBLPARAM) param, which can point to who knows how many different things depending in both control and the notification code is that of which you speak?

I use this:

#IF NOT %DEF(%LVUNION)
 UNION LvUnion
    NMHDR  AS NMHDR
    NMLV   AS NMLISTVIEW
    NMIA   AS NMITEMACTIVATE
    LVDI   AS LV_DISPINFO
    LVCD   AS NMLVCUSTOMDRAW
    NMLVK  AS NMLVKEYDOWN
    NMTVDI AS TV_DISPINFO
    NMTV   AS NM_TREEVIEW
    ' header control Note this is not the same as NMHDR
    NM_HEADER AS NMHEADER
 END UNION
 %LVUNION = 1
#ENDIF

While this is set up here only for the listview, treeview and header controls, there's no reason you could not expand it to include "anything" which might be passed by reference in lparam on WM_NOTIFY.. calendar controls, rebar controls, etc etc etc

The processing will always be the same:

 LOCAL pLVU AS LvUnion PTR 
.....

    CASE  %WM_NOTIFY 
         pLVU =    lparam    ' ALWAYS 

         SELECT CASE AS LONG @plvu.nmhdr.idfrom 
                CASE %ID_LISTVIEW 
                    something 
                CASE ^ID_TREVIEW 
                    something 
                CASE %ID_CALENDAR
                    something
...

Your real problem trying to do what you want to do is that WM_NOTIFY is not sent to the control itself, it is sent to the owner window.... unless you get that new feature suggestion implemented.

MCM

[Chris Holbrook]

Why not just send a corresponding message to the control when the dialog gets a WM_NOTIFY for that control. The child can send a message back to tell the parent what value to return to the windows class proc. I'm guessing! I would also guess that you would want to use %WM_USER.. messages.

[Michael Mattias]

If this is "last week's challenge, continued" the answer is the same:

To create a 'CONTROL' which does special processing of a WM_NOTFY message from one of the Microsoft Common Controls, register a window class, create a window, have that window create a child window of the desired Common Control type, and field all the WM_NOTIFY notifications in the window procedure for the registered class.

e.g.

FUNCTION RegisterMyControl ()  AS LONG 

  IF NOT CLass_registered 
      RegisterClassEx 
  END IF 

END FUNCTION
.....
FUNCTION MyClassProc

    CASE %WM_CREATE
          CreateWindowEx "syslistview32" .....


   CASE %WM_NOTIFY 
      whatever 

....
...
   RegisterMyClass 
   DIALOG NEW   ..... to hDlg 
   CONTROL ADD "MyClass" , HDlg...

To get DDT to separately route WM_NOTIFY messages to a procedure named in the CONTROL ADD statement, you need to change DDT. DDT will route WM_COMMAND but does not route WM_NOTIFY.

Or, you can just write a 'message cracker' just like you see with some of the GUI Tools.

  CASE %WM_NOTIFY 
        CALLProc =  GetProc (wParam, lparam)  ' determine address of callback from params
        CALL DWORD Callproc using Prototype (CBHNDL , CBMSG, CBWPARAM, CBLPARAM)

MCM

[BOB MECHLER]

All excellent tools for attacking the problem. I appreciate very much the help I'm getting here.

Thanks,

Bob Mechler