Announcement

Collapse
No announcement yet.

Windows Messages

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

  • Windows Messages

    I am working on an INC for Windows messages (Basically translates wParam and lParam into readable statements for logging, or looking up possible errors etc.

    The deeper I get though the more I find Docs only show 1 parameter or states that it takes no parameters.

    In cases like these is it safe to consider those values to be zero? or some value like Invalid_Handle? or something else I would have to pass if I were doing a SendMessage????

    I am also starting to see why no one (that I have found yet) has done this as the few messages I have documented in my code is really monotonous compared to looking up Messages in the Docs only when I use them
    Engineer's Motto: If it aint broke take it apart and fix it

    "If at 1st you don't succeed... call it version 1.0"

    "Half of Programming is coding"....."The other 90% is DEBUGGING"

    "Document my code????" .... "WHYYY??? do you think they call it CODE? "

  • #2
    >In cases like these is it safe to consider those values to be zero?

    AFAIK, for messages you send when a param is 'unused' the doc says make it zero and if not you can make it anything you'd like.

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

    Comment


    • #3
      Example:
      WM_DEVMODECHANGE
      lpszDev = (LPCTSTR) lParam; // address of device name
      No mention about what to set wParam to so I would assume it to be zero? (have not tested yet)

      and then there are ones like WM_SYSCOLORCHANGE that the docs do not state if anything is returned, or what to expect if there is a return?

      and of course my favorite (insert sarcasm here)
      WM_QUERYENDSESSION
      nSource = (UINT) wParam; // source of end-session request
      fLogOff = lParam // logoff flag
      where the parameters are described as
      nSource

      Reserved for future use.

      fLogOff

      Value of lParam. Indicates whether the user is logging off or shutting down the system. Supported values include: ENDSESSION_LOGOFF.
      Which is fine, but if ENDSESSION_LOGOFF is one of the values, what are the other values????

      I know I have a lot of research to do, and comparisons with MSDN yet to go
      Engineer's Motto: If it aint broke take it apart and fix it

      "If at 1st you don't succeed... call it version 1.0"

      "Half of Programming is coding"....."The other 90% is DEBUGGING"

      "Document my code????" .... "WHYYY??? do you think they call it CODE? "

      Comment


      • #4
        One other thing I am noticing is that most messages should return some value if processed. In most cases, since the returned value should be zero, am I getting away with these calls to my callback only because I do not return a value, so it is assumed zero?

        If this is the case then examples I see all the time for callbacks do not return a value, and should really return a value for readability and maintainability ????
        Engineer's Motto: If it aint broke take it apart and fix it

        "If at 1st you don't succeed... call it version 1.0"

        "Half of Programming is coding"....."The other 90% is DEBUGGING"

        "Document my code????" .... "WHYYY??? do you think they call it CODE? "

        Comment


        • #5
          I don't use DDT so I'm not sure what goes on there, but with SDK style I try to be extremely careful about returning exactly what the docs for a message specify. Most messages return 0 when processed, as I'm sure you know. However, a number of them do return other values. The ones that come immediately to mind for me are WM_CREATE for failure (-1 I believe), and WM_CTLCOLORSTATIC (which I believe requires a return of a HBRUSH). There are others though, of course.

          One thing, if you are sending messages, you need to use the macros that combine two 16 bit values into a 32 bit value, i.e., wParam and lParam.
          Fred
          "fharris"+Chr$(64)+"evenlink"+Chr$(46)+"com"

          Comment


          • #6
            Code:
            LRESULT CALLBACK WindowProc(
              HWND hwnd,          // handle to window
              WM_QUERYENDSESSION, // the message to send
              WPARAM wParam,      // not used
              LPARAM lParam       // logoff option
            );
            
            LRESULT CALLBACK WindowProc(
              HWND hwnd,       // handle to window
              UINT uMsg,       // WM_DEVMODECHANGE
              WPARAM wParam,   // not used
              LPARAM lParam    // device name (LPCTSTR)
            );
            Neither one of these messages is sent by an application program, so "what to set the unused parameter to" is immaterial.
            Michael Mattias
            Tal Systems (retired)
            Port Washington WI USA
            [email protected]
            http://www.talsystems.com

            Comment


            • #7
              Which is fine, but if ENDSESSION_LOGOFF is one of the values, what are the other values????
              Don't know which help file are you using (maybe one many years old?), but both the Platform SDK Help and MSDN list the following:

              ENDSESSION_CLOSEAPP
              0x00000001

              ENDSESSION_CRITICAL
              0x40000000

              ENDSESSION_LOGOFF
              0x80000000
              Forum: http://www.jose.it-berater.org/smfforum/index.php

              Comment


              • #8
                LRESULT CALLBACK WindowProc(
                HWND hwnd, // handle to window
                WM_QUERYENDSESSION, // the message to send
                WPARAM wParam, // not used
                LPARAM lParam // logoff option
                );

                LRESULT CALLBACK WindowProc(
                HWND hwnd, // handle to window
                UINT uMsg, // WM_DEVMODECHANGE
                WPARAM wParam, // not used
                LPARAM lParam // device name (LPCTSTR)
                );

                Neither one of these messages is sent by an application program, so "what to set the unused parameter to" is immaterial.
                How did you come to that conclusion?
                I am afraid your reply is wrong for both of these messages.

                In the case of WM_QUERYENDSESSION, a programmer sends this message from the window procedure of the
                MDI Frame to MDI Child windows when the application is shutting down. The WM_CLOSE message can also
                be used for this, but WM_QUERYENDSESSION is better because of the information carried by the lParam
                parameter.

                In the case of WM_DEVICEMODECHANGE, when your application changes the settings a device such as the
                printer, who do you think is responsible for broadcasting the changes to all top-level windows?
                Your app, by doing something like this
                Code:
                 
                SendMessageTimeout %HWND_BROADCAST, %WM_DEVMODECHANGE, 0, BYVAL VARPTR(szPrinterName), %SMTO_NORMAL, 1000, BYVAL %NULL
                Many messages that you think are not sent by applications usually are.

                On a related matter, a poster recently said that we don't know what DefWindowProc does. It was made by a DDT'er(the blind)
                so I let it slide. Nothing could be further from the truth. There are messages that let us query DefWindowProc for useful
                information about a window. Unfortunately, folks who are weaned on DDT don't know this. And those are messages that you
                would not normally think are sent by an application.
                For example, WM_NCCALCSIZE and WM_NCHITTEST.

                ...so "what to set the unused parameter to" is immaterial.
                Really bad advice, in my opinion. And the same goes for return values. Ignore the documentation at your peril, because
                if Microsoft were to introduce a new message in response to a particular message, you would be in trouble if the return
                value or parameters became relevant. The introduction of the WM_CONTEXTMENU message is one example that caused grief.
                Last edited by Dominic Mitchell; 29 Mar 2009, 08:10 PM.
                Dominic Mitchell
                Phoenix Visual Designer
                http://www.phnxthunder.com

                Comment


                • #9
                  Thank you Dominic,

                  I was really starting to wonder if my question was more along the lines of going to Vegas, thinking I had a "System" to beat the "House" and rolling the dice knowing that 0 = beat the house....other = lose unless I know the value would be the roll of the die


                  That said, I am more of a purist mind when told to do something (like understanding why to use 3.1415926535897932384626433832795 instead of just 3.14 in mathematical areas (I learned 3.14 may work in cases, when pi is NOT 3.14, but thats another issue)

                  Rules are RULES!!! and some can be (and will be bent), but when they break, if you do not know why they break you can not possibly find where/what/when/how they broke

                  Currently I guess my best avenue when I have questions as to what to pass is to either pass 0, or something purposely invalid (or at least my best guess given the documentation given for the function being called) and DEFINITELY at least comment points where I took my best "Guesstimation" and could be wrong (so it can be corrected in the future)
                  Engineer's Motto: If it aint broke take it apart and fix it

                  "If at 1st you don't succeed... call it version 1.0"

                  "Half of Programming is coding"....."The other 90% is DEBUGGING"

                  "Document my code????" .... "WHYYY??? do you think they call it CODE? "

                  Comment

                  Working...
                  X