Word of warning...

[mark smit]

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:

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

[Borje Hagsten]

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).]

[Steve Hutchesson]

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]

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

[mark smit]

Borje,

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

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

[Edwin Knoppert]

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

    Case %WM_CREATE

        FUNCTION = DefWindowProc( .....

        YourCustomCode()

        Exit Function

    Case Else
    End Select

    FUNCTION = DefWindowProc( .....

End Function

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

[Chris Boss]

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.


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

[mark smit]

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

[Dominic Mitchell]

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