Announcement

Collapse
No announcement yet.

WM_NOTIFY is not received in DDT during WM_INITDIALOG

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

  • WM_NOTIFY is not received in DDT during WM_INITDIALOG


    I'm using a custom control wich sents a WM_NOTIFY

    Debugging tells me the the call is been made.
    DDT does not receive the message while in WM_INITDIALOG

    What to do??

    ------------------
    hellobasic

  • #2
    Edwin,

    I'm not sure I understood you correctly, but I've wanted to send
    info to a dialog before the DIALOG SHOW statement and I used:

    Code:
       DIALOG NEW hDlg&, Title$,,, 100, 80, _
                  %WS_POPUPWINDOW OR %WS_CAPTION OR %WS_MINIMIZEBOX OR _
                  %WS_MAXIMIZEBOX OR %WS_SIZEBOX OR %WS_MAXIMIZE TO hDlg2&
    
       PostMessage hDlg2&, %WM_USER+1, x&, y& 'Pass data
    
       ' ** Display the dialog
       DIALOG SHOW MODAL hDlg2&, CALL DlgProc TO Result&


    ------------------
    Bernard Ertl
    Bernard Ertl
    InterPlan Systems

    Comment


    • #3
      Edwin --

      I'm not sure I understand either. WM_INITDIALOG and WM_NOTIFY are two different messages. How could WM_NOTIFY be sent while you are "in" WM_INITDIALOG? At most they would be sent sequentially, one immediately after the other.

      Hmmm... unless, that is, something in your WM_INITDIALOG handler is causing WM_NOTIFY to be sent? Is that what you are saying?

      -- Eric


      ------------------
      Perfect Sync Development Tools
      Perfect Sync Web Site
      Contact Us: mailto:[email protected][email protected]</A>

      [This message has been edited by Eric Pearson (edited June 16, 2001).]
      "Not my circus, not my monkeys."

      Comment


      • #4
        Bernard,
        I'm using a postmessage at the moment.

        My question was wrong, i wanted it to be confirmed.

        Eric,
        I am creating a custom control during init.
        The control notifies the parent of a certain state.
        In this case right after creation.
        This all happens while WM_INITDIALOG is still processing of course.
        I can not imagne, Windows blocks these messages during this period.

        This is the order:

        WM_INITDIALOG
        > CreateWindow
        < Send Parent a notify
        Return from creation
        Exit WM_INITDIALOG




        ------------------
        hellobasic

        Comment


        • #5
          Edwin;

          The problem is PostMessage. While SendMessage sens a message
          immediately, PostMessage waits until all other messages
          in the que are completed first, which would include WM_INITDIALOG.

          So if you create a control in WM_INITDIALOG and expect it to send
          a WM_NOTIFY messages to its parent upon its creation, the message
          can't get there during WM_INITDIALOG if you use PostMessage.



          ------------------
          Chris Boss
          Computer Workshop
          Developer of "EZGUI"
          http://cwsof.com
          http://twitter.com/EZGUIProGuy

          Comment


          • #6
            The problem is PostMessage. While SendMessage sens a message
            immediately, PostMessage waits until all other messages
            in the que are completed first, which would include WM_INITDIALOG.
            Chris, that is incorrect. SendMessage is synchronous while PostMessage is
            asynchronous. That is, PosMessage returns immediately while SendMessage
            waits until the message is processed before returning. That means that the
            calling thread does not know when a posted message will be processed and its
            quite possible that the window specified in the message will never receive
            the posted message. With SendMessage the calling thread knows that the
            message has been completely processed before the next line of code executes.
            That is why SendMessage can be used as a simple form of thread synchronization.

            ------------------
            Dominic Mitchell
            Dominic Mitchell
            Phoenix Visual Designer
            http://www.phnxthunder.com

            Comment


            • #7
              Dominic;

              While the API docs may give the impression that what I said isn't true,
              my description above is quite accurate.

              SendMessage sends the message directly to the Window procedure
              of a window, so it must be processed before SendMessage returns.
              This is why SendMessage acts synchronous as you said.

              Now calling PostMessage asynchronous is not quite right, just because the
              API docs say the function returns immediately. The message isn't processed
              asynchronously ! The message in fact is simply posted to the message queue for
              the current applications thread. You might say, the message is simply
              pending and it will not be processed until GetMessage gets the message from
              the queue. Now the message queue processes messages in a FIFO fashion,
              which means the Posted Message is the last message to get processed.

              This means the WM_INITDIALOG message will finish being processed before
              the posted message ever gets pulled out of the message queue, so it doesn't get
              processed during the WM_INITDIALOG message. This explains Edwins
              problem.

              PostMessage is easily misunderstood in its usage. To be truly asynchronous
              it would have to be processed in another thread and it is not. It is
              still processed in the same thread as the thread that called postmessage.




              ------------------
              Chris Boss
              Computer Workshop
              Developer of "EZGUI"
              http://cwsof.com
              http://twitter.com/EZGUIProGuy

              Comment


              • #8
                Chris,
                Your reply is a gross simplification of what really occurs.
                A thread's message queue consists of a data structure that identifies a
                posted-message queue, send-message queue, reply-message queue, virtualized
                input queue, wake flags etc.
                SendMessage sends the message directly to the window procedure of a window
                only if that window was created by the same thread. If the window
                was created by a different thread the message is first appended to the message
                queue of the receiving thread.
                PostMessage does not have to be processed by another thread to be asynchronous.
                Also, the queues are not FIFO stacks in the true sense. For example, posted
                messages are always returned before keyboard and mouse messages; keyboard and
                mouse messages are always returned before paint messages; paint messages are
                always returned before timer messages. Also, message filtering affects the
                order that messages are pulled from the queue.
                This priority based on the type of message can be very useful when designing applications.

                For detailed analyses of threads and message queues see the following-

                "GetMessage and PeekMessage internals" by Bob Gunderson in MSDN
                Advanced Windows by Jeffrey Richter, "Windows Messages and Asynchronous Input"
                Multithreading Applications in Win32 by Jim Beveridge and Robert Wiener.

                ------------------
                Dominic Mitchell
                Dominic Mitchell
                Phoenix Visual Designer
                http://www.phnxthunder.com

                Comment


                • #9
                  Edwin --

                  IMO most of those details (while genuinely interesting and worthy of discussion) are not pertinent to your question and you don't need to understand them to solve your problem.

                  The behavior of SendMessage and PostMessage are similar to the SHELL statement and SHELL function, respectively.

                  SendMessage tells a window proc "process this message and give me the result". So any code that calls SendMessage will pause until the message has been processed, i.e. until a return value has been provided. That can't happen until the message is processed.

                  PostMessage tells a window proc "process this message when you get a chance, and discard the result because I will have moved on by then". As soon as Windowws places the message in a message que, the PostMessage function returns and the code that called PostMessage can continue. The actual message will be processed at some point in the future. In some cases, depending on how busy the system is, it can take many seconds.

                  So when you use PostMessage there is no way to predict when the message will be processed. If you want your message to be processed before you finish your %WM_INITDIALOG code, you must use SendMessage, not PostMessage.

                  -- Eric


                  ------------------
                  Perfect Sync Development Tools
                  Perfect Sync Web Site
                  Contact Us: mailto:[email protected]s[email protected]</A>



                  [This message has been edited by Eric Pearson (edited June 17, 2001).]
                  "Not my circus, not my monkeys."

                  Comment


                  • #10

                    I am not sure if this is what Edwin meant but this code I believe shows a problem with
                    DIALOG SEND from within the WM_INITDIALOG handler.
                    (tested only on Win2k)

                    James

                    Code:
                    '=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
                    'Note: Click Just Cancel and gl& = 0 showing that the DIALOG SEND in WM_INITDIALOG is
                    '      Failing.
                    '------------------------------------------------------------------------------
                    'Click Ok and the Msg is processed.
                        
                    
                    #COMPILE EXE
                    #DIM ALL
                    #REGISTER NONE
                    #INCLUDE "WIN32API.INC"
                    
                    %DLG_100_PB_OK = 101
                    %DLG_100_PB_CANCEL = 102
                    %DLG_100_PB_OK = 101
                    %MY_MSG = %WM_USER + 1
                    GLOBAL gl&
                    '==============================================================================
                    CALLBACK FUNCTION _
                      DLG_100_PB_CANCEL_CB AS LONG
                      
                      DIALOG END CBHNDL
                    END FUNCTION  
                    '==============================================================================
                    CALLBACK FUNCTION _
                      DLG_100_PB_OK_CB AS LONG
                        DIALOG SEND CBHNDL,%MY_MSG,0,0
                        MsgBox "DIALOG SEND CBHNDL,%MY_MSG,0,0"
                        DIALOG END CBHNDL
                    END FUNCTION  
                    '==============================================================================
                    '===========================================================================
                    CALLBACK FUNCTION _ 
                      DLG_100_CB AS LONG
                    
                      SELECT CASE CBMSG
                        CASE %WM_INITDIALOG
                          DIALOG SEND CBHNDL,%WM_SETICON,1,LoadIcon(0,BYVAL %IDI_APPLICATION)
                          DIALOG SEND CBHNDL,%MY_MSG,0,0
                        CASE %MY_MSG  
                          gl&=10
                          FUNCTION = 1
                      END SELECT
                    END FUNCTION
                    '===========================================================================
                    FUNCTION _ 
                      Create_DLG_100 ( _
                        BYVAL hParent		AS LONG _
                      ) AS LONG
                    
                      DIM hDlg                              AS LONG
                      DIM lRetVal                           AS LONG
                    '---------------------------------------------------------------------------
                      DIALOG NEW hParent, _
                                "", _
                                0, _
                                0, _
                                240, _
                                120, _
                                %DS_MODALFRAME OR %DS_3DLOOK OR %WS_OVERLAPPED OR %WS_VISIBLE OR %WS_CAPTION OR %WS_SYSMENU, _
                                %WS_EX_DLGMODALFRAME, TO hDlg
                      
                    '---------------------------------------------------------------------------
                      CONTROL ADD BUTTON, _
                                  hDlg, _ 
                                  %DLG_100_PB_OK, _
                                  "OK", _
                                  186, _
                                  6, _
                                  50, _
                                  14, _
                                  %BS_PUSHBUTTON OR %BS_CENTER OR %WS_CHILD OR %WS_VISIBLE OR %WS_TABSTOP, _
                                  , CALL DLG_100_PB_OK_CB
                    '---------------------------------------------------------------------------
                      CONTROL ADD BUTTON, _
                                  hDlg, _ 
                                  %DLG_100_PB_CANCEL, _
                                  "Cancel", _
                                  186, _
                                  26, _
                                  50, _
                                  14, _
                                  %BS_PUSHBUTTON OR %BS_CENTER OR %WS_CHILD OR %WS_VISIBLE OR %WS_TABSTOP, _
                                  , CALL DLG_100_PB_CANCEL_CB
                      DIALOG SHOW MODAL hDlg,CALL DLG_100_CB TO lRetVal
                      FUNCTION = lRetVal
                    END FUNCTION
                    '===========================================================================
                    FUNCTION _
                      PbMain ( _
                      )AS LONG
                      
                      Create_Dlg_100 0
                      MsgBox FORMAT$(gl&)
                    END FUNCTION
                    ------------------

                    Comment


                    • #11
                      Guys --
                      don't forget that DDT is subclassed.
                      Code:
                         #Compile Exe
                         #Dim All
                         #Register None
                         #Include "WIN32API.INC"
                      
                         CallBack Function DlgProc As Long
                            Select Case CbMsg
                               Case %WM_INITDIALOG
                                  MsgBox Hex$(getWindowLong(CbHndl, %GWL_WNDPROC)),, Hex$(CodePtr(DlgProc))
                            End Select
                        End Function
                      
                        Function PbMain
                           Dim hDlg As Long
                           Dialog New 0,  "", , , 240, 120 To hDlg
                           Dialog Show Modal hDlg Call DlgProc
                        End Function
                      SendMessage works fine, but ... in original proc.
                      Executing Dialog Show, DDT imitates WM_INITDIALOG (real event already was in Dialog New) and in this moment doesn't transfer message to DlgProc).

                      Summary. Windows works as expected. DDT works like Bob wrote.


                      ------------------
                      E-MAIL: [email protected]

                      Comment


                      • #12
                        Semen,
                        I think you are right and confirmes my tought.

                        Chris,
                        I use postmessgae only to SOLVE my problem
                        I don't wanted to use it.

                        As i said to semen, i think the DDT messagepump is not transferring all messages properly whil being in the WM_INIT.

                        I added another sendmessage IN WM_INITDIALOG to instruct my control.
                        This results in another problem.
                        These problems do not occure if i use postmessage from the WM_INIT like:

                        Case %WM_INITDIALOG
                        PostMessage 10000

                        Case 10000

                        Do all stuff here...

                        This is no good if you try to build a good control..

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


                        [This message has been edited by Edwin Knoppert (edited June 18, 2001).]
                        hellobasic

                        Comment

                        Working...
                        X