Announcement

Collapse
No announcement yet.

%Wm_User + (various numbers)

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

  • %Wm_User + (various numbers)

    I see "%Wm_User + (various numbers)" used quite often
    in code snippets. In the WIN32API it shows
    "%Wm_User = 0400h" (IIRC). So far so good. But Also in
    the WIN32API are several constants defined as
    "%Constant = %Wm_User + (various numbers)".

    Isn't there a risk of a programmer using
    "%Wm_User + (various numbers)" conflicting or overlapping
    with a WINAPI constant assigned the same number?

    Just curious.

    ------------------
    Thx............Gösta
    mailto:[email protected][email protected]</A>
    http://www.SwedesDock.com
    http://www.PondersBible.com
    It's a pretty day. I hope you enjoy it.

    Gösta

    JWAM: (Quit Smoking): http://www.SwedesDock.com/smoking
    LDN - A Miracle Drug: http://www.SwedesDock.com/LDN/

  • #2
    Gosta;

    When you read the API docs about WM_USER you find that
    there is a block of message values that are for custom
    messages for any window class. The docs refer to them
    a private messages.

    The range is from WM_USER to h7FFF .

    What is a private message ?

    Windows uses the values below WM_USER for all of its
    standard window messages (ie. WM_CREATE, WM_DESTROY, etc.).

    When a window class is created, there may be a need for
    custom (or private) messages unique to that window class.

    Since you can't use values below WM_USER, you must use the
    range of WM_USER to h7FFF for private messages. This way you
    know that no standard window message will conflict with your
    custom/private messages.

    Now this is where it may get confusing:

    A predefined window class (controls, dialogs, etc.) may have
    already used some of those private message values.

    If you create the window class yourself (RegisterClass and then
    Createwindow to create it), you personally define any private
    messages. If you use a predefined class , you need to know if
    any private messages have been defined for it.

    Now for some examples:

    The standard Dialog class has just a few predefined private messages,
    such as DM_GETDEFID (WM_USER + 0) and DM_SETDEFID (WM_USER + 1).
    Aside from these two unique private messages, there shouldn't be
    any others to worry about.

    The common dialogs (Open/Save/Printer) each have a set of
    private messages defined, so you have to be aware of them as well.

    Fortunately, for us, even with these predefined private messages,
    most (if not all) windows classes defined by Windows itself, have
    a standard method of always defining private messages starting
    from WM_USER and simply incrementing by 1, so most private messages
    will fall into the range of WM_USER to WM_USER + 200 (maybe a little
    more in some cases).

    I follow this standard for all the custom control classes I write.
    I have written a number of custom controls and I always define the
    private messages starting with WM_USER and rarely will they ever
    go higher than WM_USER +100.

    Now what good are private messages for a windows programmer ?

    If you create the window class yourself (ie. SDK style window class
    or a custom control class), you get to define all
    the private messages yourself and they are not only useful but
    important. As long as they start from WM_USER you are fine !

    When working with a predefined window class (ie. Dialog class,
    for example used by DDT), you don't really have to worry too
    much about the private messages, since there should be some
    documentation in the API docs of what private messages are
    used by that window class.

    The Dialog class only uses two private messages that I know of
    , DM_GETDEFID (WM_USER + 0) and DM_SETDEFID (WM_USER + 1), so
    anything above these should be OK.

    Now of course you may worry about some conflict with existing
    private messages, so I find that a very common practice when
    defining your own private messages for a predefined window class
    (ie. Dialogs) is to use the following for the start of your
    private messages:

    WM_USER + 400

    Since most window classes start their private messages at WM_USER
    and they increment them by 1's or 10's, likely few private messages
    go as high as WM_USER + 400. By defining all your private (custom)
    messages starting at WM_USER + 400, it is very unlikely that you
    will conflict with an existing private messages.

    Try searching the win32api.inc and commctrl.inc files for the
    %WM_USER value and you will see that all the private messages
    defined will fall below WM_USER + 400. You will find that most
    fall below WM_USER + 100, nearly all below WM_USER + 200 and
    absolutely all of them below WM_USER + 400.

    Now remember each private message is only good for the window
    class it was defined for. So the private messages for the
    toolbar have nothing to do with any other window class. The
    private messages for the Dialog class have nothing to do with
    any other window class and so on.

    Custom Private messages aren't really of any use unless you have
    access to the window classes window (or dialog) procedure. This
    means that for the control classes, unless you subclass (or
    superclass) the controls, you couldn't use any custom private messages
    anyway. Now since Dialogs give you access to a Dialog procedure
    (not exactly the same as window procedure but simliar), you may
    use custom private messages with them. One example is creating tray icons.
    This requires creating a custom private message. But as I mentioned
    as long as you start with WM_USER + 400, I doubt you will ever have
    a problem with a conflict with existing private messages.

    Just a note:

    I have often seen window code where programmers define their
    control ID values by using WM_USER + some number. This is
    not necessary ! A control ID is not a window message !

    The only ID values to be concerned about are below 15 (ie. some
    predefined for cancel and OK button in dialog class).

    IDOK = 1
    IDCANCEL = 2
    IDABORT = 3
    IDRETRY = 4
    IDIGNORE = 5
    IDYES = 6
    IDNO = 7
    IDCLOSE = 8
    IDHELP = 9
    IDTRYAGAIN = 10

    I usually start with 100 for control class ID's just to be safe.




    [This message has been edited by Chris Boss (edited April 08, 2003).]
    Chris Boss
    Computer Workshop
    Developer of "EZGUI"
    http://cwsof.com
    http://twitter.com/EZGUIProGuy

    Comment


    • #3
      Great (and complete) explanation, Chris. Thanks. Believe it or not
      I think I grasped most of it. The day I create a class on my own
      is a long way off yet I believe {grin}.

      I was confused between Control ID's and messages. I see the
      difference better now. Still don't fully grasp "messages"
      but much closer now.

      I'm still being blown away with the power and speed of PBWin.
      And this forum. Yesterday I spent the day studying and incorporating
      Borje's VirtualListBox control into my code. Stuffs 40,000+ elements
      into a Listbox in about a half second. Nothing short of Astounding.

      Believe I just contradicted myself. To use the VLB a class did have to
      be created. Cut & Paste Borje's code, though, .... but a start.

      Thanks your complete (and comprehensible) reply.

      I nominate you to be the moderator of the Newby Forum!

      ------------------
      Thx............Gösta
      mailto:[email protected][email protected]</A>
      http://www.SwedesDock.com
      http://www.PondersBible.com



      [This message has been edited by Gösta H. Lovgren-2 (edited April 09, 2003).]
      It's a pretty day. I hope you enjoy it.

      Gösta

      JWAM: (Quit Smoking): http://www.SwedesDock.com/smoking
      LDN - A Miracle Drug: http://www.SwedesDock.com/LDN/

      Comment


      • #4
        If you want a <U>unique</U> "window message number" you can always use RegisterWindowMessage.

        Of course, this is only necessary if you send messages to non-cooperating applications.

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

        Comment


        • #5
          And keep in mind that you and the API may not be the only ones who are using WM_USER messages. For example if you use the Farpoint Spread 6.0 grid in your program you'll find that it uses a block of messages starting with WM_USER+&h100. Other Farpoint products use other ranges (like WM_USER+&H350 and WM_USER+&H400), to avoid conflicts among their products.

          If your module is a DLL that will be used with Visual Basic you have to avoid conflicting with messages in the WM_USER+&hC00 (&h1000) range.

          My company's Graphics Tools Version 2 product currently uses messages in the WM_USER+&h3C00 (&h4000) range.

          Your programs, of course, need to avoid all of the ranges that are used by the third-party products that you are using.

          -- Eric


          ------------------
          Perfect Sync Development Tools
          Perfect Sync Web Site
          Contact Us: mailto:[email protected][email protected]</A>
          "Not my circus, not my monkeys."

          Comment


          • #6
            Don't understand. There's no risk using whatever WM_USER number inside a
            custom control, since calls to it is "private" via its handle. But when it
            comes to sending messages from control to parent, one has to be careful.

            Then best to use MS way and send as WM_COMMAND or WM_NOTIFY and make
            sure handle/id of sending control also is sent, so it becomes possible
            to filter out from where it's sent.

            This of course also works with identical messages like WM_USER + 1 from
            two separate controls, as long as one parameter includes the handle and/or
            id of sending control so it becomes possible to identify sender. Or..?


            ------------------
            http://www.tolkenxp.com/pb
            Download: incLean, PBcodec, custom controls and code, etc.
            Borje Hagsten - [email protected]

            Comment


            • #7
              Borje;

              When I write custom controls, I avoid using any private messages
              to the parent Dialogs window procedure !

              I send all event messages to the parent via WM_COMMAND and
              WM_NOTIFY, so no private messages needed. This is the best way
              IMO.

              For those who write custom controls for use with PB, it is best
              to always pass messages via WM_COMMAND and WM_NOTIFY. Since
              WM_NOTIFY was designed for handling complex messages, there isn't
              much you can do with it.

              Eric is right about making sure that any third party tools
              you use don't use private messages in the range you want to use.

              Currently EZGUI 3.0 will use private messages from WM_USER + 399
              to WM_USER + 510 .



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

              Comment


              • #8
                Why not use %WM_APP messages?



                ------------------
                Paul Squires
                Cheetah Database System - "Nothing runs like a Cheetah"
                JellyFish Pro Editor - "Custom code editor for PowerBasic"
                www.planetsquires.com
                mailto:[email protected][email protected]</A>
                Paul Squires
                FireFly Visual Designer (for PowerBASIC Windows 10+)
                Version 3 now available.
                http://www.planetsquires.com

                Comment


                • #9
                  I agree with Borje Hagsten in useing the WM_COMMAND interface,
                  this message means "do something" and its very flexible in how
                  you can use it.

                  I occasionally use RegisterWindowMessage() for inter application
                  communication if it doesn't warrant a memory mapped file and this function
                  is supposed to garrantee a unique ID for the message. I have yet to
                  find a use for private messages that take up the specified range.

                  Regards,

                  [email protected]

                  ------------------
                  hutch at movsd dot com
                  The MASM Forum

                  www.masm32.com

                  Comment


                  • #10
                    Originally posted by Paul Squires:
                    Why not use %WM_APP messages?
                    %WM_APP = &H08000. The confusion here is that the older MS doc's say:
                    Code:
                    0x8000 through 0xBFFF	Messages reserved for future use by Windows.
                    ...but the current MS doc's say:
                    Code:
                    WM_APP through 0xBFFF Messages available for use by applications.
                    The moral? If it's a really critical notification message use RegisterWindowMessage(); otherwise use %WM_USER+n or %WM_APP+n messages with either range producing a small risk of conflict if messages of these values are sent to a dialog/window callback.


                    ------------------
                    Lance
                    PowerBASIC Support
                    mailto:[email protected][email protected]</A>
                    Lance
                    mailto:[email protected]

                    Comment

                    Working...
                    X