Announcement

Collapse
No announcement yet.

DIALOG CALLBACK question.

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

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

    Thanks,

    Bob Mechler

    Leave a comment:


  • Michael Mattias
    replied
    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.
    Code:
    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.
    Code:
      CASE %WM_NOTIFY 
            CALLProc =  GetProc (wParam, lparam)  ' determine address of callback from params
            CALL DWORD Callproc using Prototype (CBHNDL , CBMSG, CBWPARAM, CBLPARAM)




    MCM

    Leave a comment:


  • Chris Holbrook
    replied
    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.

    Leave a comment:


  • Michael Mattias
    replied
    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:
    Code:
    #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:

    Code:
     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

    Leave a comment:


  • BOB MECHLER
    started a topic DIALOG CALLBACK question.

    DIALOG CALLBACK question.

    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.

    Code:
        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
Working...
X