Announcement

Collapse
No announcement yet.

Word of warning...

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

  • Word of warning...

    Hi all,


    I don't want to scare anybody with that subject line but I found something out over the week-end that may be of some use. When you use SetWindowLong(hWnd,%GWL_USERDATA,value) while processing the WM_CREATE message the value is overwritten and reset to zero in following messages.

    EXAMPLE:
    Code:
    select case (message)
        case %WM_CREATE
            SetWindowLong hWnd,%GWL_USERDATA,256
            PostMessage hWnd,%WM_USER,0,0
    
        case %WM_USER
            msgbox str$(GetWindowLong(hWnd,%GWL_USERDATA))
            rem message box will return zero here for me.
    end select
    I think this has somthing to do with the window not really existing yet

    Any comments?

    ------------------
    Cheers

  • #2
    I think DDT engine uses %GWL_USERDATA for its own purposes, in case
    you have used DIALOG NEW, CONTROL ADD, etc..


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


    [This message has been edited by Borje Hagsten (edited February 05, 2001).]

    Comment


    • #3
      YES,

      In the WM_CREATE message, you do not yet have a window handle from the CreateWindowEx()
      function so you MUST use the window handle passed to the WndProc.

      Safest place to set a Wndow's memory is AFTER the CreateWindowEx() function.

      Regards,

      [email protected]

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

      www.masm32.com

      Comment


      • #4
        Borje,

        I know that DDT uses this but I came accross this when writing a custom control. I'm just using CreateWindow API.

        ------------------
        Cheers

        Comment


        • #5
          Most often i return the WM_CREATE params directly to the callwindowproc or defwindowproc first.
          Then add custom stuff:

          Code:
              Case %WM_CREATE
          
                  FUNCTION = DefWindowProc( .....
          
                  YourCustomCode()
          
                  Exit Function
          
              Case Else
              End Select
          
              FUNCTION = DefWindowProc( .....
          
          End Function
          ------------------
          hellobasic

          Comment


          • #6
            Mark;

            You can use the API function PostMessage (not SendMessage)
            to send your window procedure a custom message (you need to create
            one above %WM_USER or if not using DDT or Windows Dialog engine
            you can reuse %WM_INITDIALOG) from the %WM_CREATE message. Then
            initialize what ever you want in that custom message, rather than
            in WM_CREATE.

            PostMessage will let windows finish the WM_CREATE message before the
            custom message gets sent and then processed.

            Its a simple trick but it works.


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

            Comment


            • #7
              Thanks guys!


              There are some very interesting ways to deal with this problem. I hope this little thread helps some others that might have run into this.

              ------------------
              Cheers

              Comment


              • #8
                Mark,
                What you are seeing is rather odd. The traditional place for initializing data
                assigned to GWL_USERDATA or extra window bytes is in WM_CREATE. The handle used
                in WM_CREATE is the same handle that is returned by CreateWindowEx. I tested
                your code and it returned 256 as expected in WM_USER. I would really like to see
                your code because what you are seeing does not make any sense.
                A tip. When designing a custom control that is to be used by other programmers
                avoid using GWL_USERDATA for storing the state information for the control. Leave
                this memory location free so that users of your control will have an easier time
                subclassing or storing unique data for each instance of it. Use extra window bytes
                or window properties, you have a lot of them to play with.


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

                Comment

                Working...
                X