Announcement

Collapse
No announcement yet.

WMSYSCOMMAND DIALOG SC_CLOSE anomaly?

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

  • #21
    Posting and Sending messages:

    This relates to the two API functions:

    PostMessage
    SendMessage

    They are similiar but work differently.

    SendMessage sends a message directly to the window procedure of a window. It does not return until the message has been processed.

    PostMessage sends a message (posts) to the message queue of the application and immediately returns. The message is not processed immediately, but waits in the message queue. The message queue is read by calling the GetMessage API function in a message loop. The messages normally are processed in FIFI (First In, First out) order. When the message loop gets a message from the message queue, it then calls an API which handles the message (ie. IsDialogMessage, TranslateMessage) and those API functions will send the message to the window procedure of the window.

    There is a reason why some messages are better posted, while others sent directly. I won't go into all the details of importance of each method, but suffice it to say, that both methods are very important.
    Chris Boss
    Computer Workshop
    Developer of "EZGUI"
    http://cwsof.com
    http://twitter.com/EZGUIProGuy

    Comment


    • #22
      I've resolved to work out where to put my event code by writing a C app (having downloaded a suitable
      IDE and compiler) to do it, then reverse it into PB.
      You will just end up with a system similar to that used by Phoenix or FireFly.
      Dumping all notifications from a control to its parent to a single procedure is not difficult.
      For example, if this procedure is prototyped as

      Code:
      FUNCTION <ControlName>_Handler _
        ( _
        BYVAL hWnd    AS DWORD, _ ' window handle
        BYVAL uMsg    AS DWORD, _ ' type of message
        BYVAL wParam  AS DWORD, _ ' first message parameter
        BYVAL lParam  AS LONG _   ' second message parameter
        ) AS LONG
      just forward messages such as WM_COMMAND, WM_NOTIFY, WM_MEASUREITEM, WM_DRAWITEM, WM_CTLCOLORXXX,
      WM_CHARTOITEM, WM_VKEYTOITEM and WM_PARENTNOTIFY to the handler.
      If you want to include other messages such as WM_KEYDOWN, WM_MOUSEMOVE and WM_NCCALCSIZE, subclass
      or superclass the control and forward these messages to the handler.

      For parent notifications(WM_COMMAND etc.), I would probably set the value of the hWnd parameter to
      the handle of the control to keep things consistent.
      Dominic Mitchell
      Phoenix Visual Designer
      http://www.phnxthunder.com

      Comment


      • #23
        SendMessage sends a message directly to the window procedure of a window. It does not return until the message has been processed.
        The use of the word directly makes your statement a bit inaccurate.

        That is true only if the window was created by the calling thread.
        If it was, the window procedure for the window is called directly.
        If it was not, the message is queued in what is known as the Send-Message queue.
        The OS waits until the receiving thread is idle before calling the window procedure
        of the target window.
        Dominic Mitchell
        Phoenix Visual Designer
        http://www.phnxthunder.com

        Comment


        • #24
          My basic pre-supposition is that ALL users are nasty, illogical, demented, mean, preoccupied, even downright evil. And I have given up on them. No longer do I impose my ethical preconceptions on them as elucidated by Peter...

          ....I find it bad practice to start with if a user clicks [X] to end the program...
          Being as my nature is basically a pessimist, and it is so easy to trap WM_CLOSE messages in SDK style, whatever processing needs to occur when the user [X]'s the window, I put that in something like this...

          Code:
          Function fnWndProc_OnClose(parameters...)
          ...
          ...
          ...
          
            FnWndProc_OnClose=0
          End Function
          ...and everybody lives happily everafter.
          Fred
          "fharris"+Chr$(64)+"evenlink"+Chr$(46)+"com"

          Comment


          • #25
            My comments about SendMessage were assuming the standard single thread (main GUI thread) model of most applications, so for all practical purposes, my description is correct.

            Multi-Threading is a totally different situation requiring a full explanation of how threads work before one will appreciate the handling of functions like SendMessage to another thread.
            Chris Boss
            Computer Workshop
            Developer of "EZGUI"
            http://cwsof.com
            http://twitter.com/EZGUIProGuy

            Comment


            • #26
              Not that getting sidetracked is such a bad thing - I often learn from these excursions and I'm certain others do as well - but in this case we seem to have really gone off the beaten path.


              The original question was.....
              Looking at ways to close the application.
              ... and the "what I've tried" was various combinations of PostQuitMessage and sending WM_SYSCOMMAND/SC_CLOSE.

              Then this discussion got into sending versus posting messages, modifying message loops and even multi-threaded applications.

              I'm just hoping the correct solutions - which are here - have not been lost in the traffic...since this is an important topic especially for the "lurking newbies."

              - PostQuitMessage() is a mechanism for ending an SDK-style message loop and is often used to end a program... or at least the program's primary thread of execution.

              - The WM_SYSCOMMAND/SC_CLOSE notification is generated by Windows in response to a specific user action and should not be sent or posted by the application program via code. Using either SDK-style or DDT-Style coding, the default action in response to WM_SYSCOMMAND/SC_CLOSE is to destroy the window.

              - A program should always destroy its screen (with EndDialog, DestroyWindow or DIALOG END) before exiting its message loop.

              - When a window is destroyed, a WM_DESTROY notification is sent to the window procedure, allowing the program to use PostQuitMessage at that time, if that is how the programmer wants to end his message loop.

              MCM
              Michael Mattias
              Tal Systems (retired)
              Port Washington WI USA
              [email protected]
              http://www.talsystems.com

              Comment


              • #27
                If you look at the original code posted by Chris in starting this thread, the core problem he was having was trying to process the WM_SYSCOMMAND message in the message loop.

                IMO, this was based on a "common" misconception that all messages go through the message loop.

                This is incorrect.

                I tried to post working code examples, as well as detailed explanations about how messages are handled (which required understanding such things as sending/posting messages, the message queue and the message loop) so one can appreciate why trying to process certain messages in the message loop will not work.

                If one understands how messages are handle by Windows, then one will know when you can trap messages in the message loop (I do it in my software) and when they shouldn't be.

                Often problems in writing Windows applications correctly originates with misunderstandings of how Windows actually works. The more basic information one has about the core workings of Windows, the better ones code will be.

                The background I posted was quite warranted for the original question asked.
                Chris Boss
                Computer Workshop
                Developer of "EZGUI"
                http://cwsof.com
                http://twitter.com/EZGUIProGuy

                Comment


                • #28
                  Perhaps we were sidetracked but I found Chris' post #9 an eye opener. The SDK says of GetMessage "The function dispatches incoming sent messages until a posted message is available for retrieval."

                  This explains why without the EXIT LOOP that I added, SC_CLOSE is 'picked up' twice. It is clear now that Close or Alt F4 notifications are posted by Windows whereas Close via 'X' is sent, not that it matters in anything that I write.

                  Added: We can see what is going on another way by commenting out "If App_ExitFlag& Then Exit Loop ' terminate app" and adding "Function = %TRUE" in the CallBack (with the EXIT LOOP inserted as mentioned). Closing via 'X' now gets throttled.
                  Last edited by David Roberts; 10 Jan 2008, 02:11 PM.

                  Comment


                  • #29
                    This thread which has gone way beyond answering my original question and will no doubt be an education to new users who like me have skimped on the fundamentals in their haste to produce windows applications (it's really shocking that PB allows one to do this!).

                    I've gleaned several useful facts and again am impressed and humbled by the effort that "those who know" have put in to explain their reasoning.

                    Also noting that the "meat" of this thread is a little at odds with its title, I've put a suggestion onto the cafe forum here
                    Last edited by Chris Holbrook; 10 Jan 2008, 04:54 PM. Reason: added link

                    Comment


                    • #30
                      new users who like me have skimped on the fundamentals in their haste to produce windows applications
                      Ya think there might be some others? Really?

                      I am shocked, shocked!

                      MCM
                      Michael Mattias
                      Tal Systems (retired)
                      Port Washington WI USA
                      [email protected]
                      http://www.talsystems.com

                      Comment

                      Working...
                      X