Hi Donkey,

That's correct.

I also verified that this is true through testing.

The only problem is that I couldn't figure out the right return value.

Various values basically worked, but returned funny looking windows.

Since I really have no reason to use WM_NCCALCSIZE (at least at this time) I fall through and get the handle in the defwndproc which seems to work fine.

Mike
Posted on 2004-06-27 20:52:10 by msmith
Hi donkey,
Actually, the quote I posted is as accurate as copy/paste can be.

MSDN page for CreateWindow (not CreateWindowEx)

Of course, CreateWindow() is just a macro that calls CreateWindowEx().
Using both calls (with dwExStyle parameter set to zero in CreateWindowEx()) the following messages are sent to the window (ordered):


    [*]0x24 (WM_GETMINMAXINFO)
    [*]0x81 (WM_NCCREATE)
    [*]0x83 (WM_NCCALCSIZE)
    [*]0x1 (WM_CREATE)


    Please run your own test before your next reply.
Posted on 2004-06-27 21:56:37 by death
Hi death,

Yup you're right, I always thought they were the other way around, but I have to admit that I was never interested enough to ever bother to check. However it is a side issue that is only slightly related to the problem at hand.

I think what is happening is that the DefWindowProc is being called with the OBMain handle before it is defined (since it is defined after CreateWindowEx returns) and the pre-WM_CREATE messages are not being properly sent to the DefWindowProc. A good way of checking this is to verify the handle that is being dispatched to the DefWindowProc.
Posted on 2004-06-27 22:31:56 by donkey
Yes, that is the problem indeed. I mentioned this on my first post in this thread.
Posted on 2004-06-28 01:50:26 by death
Hi Donkey and Death,

Thank you both for your help.

It's all working now.

It seems that in your last couple of posts (and some before) that:



proc WindowProc, !hwnd,wmsg,wparam,lparam

...

defwndproc:
mov eax,[!hwnd]
mov [!OBMain+44],eax
invoke DefWindowProc,[!OBMain+44],[wmsg],[wparam]


Has problems. If this is not true then... nevermind.

Otherwise, I am saying that if it is ok to use !hwnd in the DefWindowProc, then it must surely be ok to copy that value to
!OBMain+44 and use it.

Since I currently don't use any of the messages you two have been discussing, I will surely fall through to DefWindowProc.

The only problem I see with this is that I will sometimes redundently set !OBMain+44 when passing through the DefWindowProc.
Posted on 2004-06-28 10:20:37 by msmith
Hmm, what happens if you use the same window procedure to process more than one
window at a time? In this case your example wont work. Youll keep resetting the
!OBMain+44 to different handles depending on who last called the DefProc.

I would do as was previously suggested. Outside of the message loop use the return
value from CreateWindowEx and inside the loop use hWnd (first param for callback function).
You will find over time, when your programs get more complicated, it will lead to less errors
and headaches... the above is just one example, I am sure there are others as well.


The only problem I see with this is that I will sometimes redundently set !OBMain+44 when passing through the DefWindowProc


Heh, depending on the application type, you could end up resetting that value hundreds
of times a second.
Posted on 2004-06-28 11:31:32 by Graebel
Hi Graebel,

Thanks for the advice.

I do have a need to use the global handle inside the proc, but I think I have made things cleaner by the following change:



proc !WindowProc,!hwnd,wmsg,wparam,lparam
enter
push ebx esi edi
cmp [wmsg],WM_GETMINMAXINFO
jne NotwmGetMaxInfo
mov dword edi,[!hwnd]
mov dword [OBMain],edi
mov dword [!OBMain+44],edi
mov dword [!OBMain+8],0
jmp !DefWndProc
NotwmGetMaxInfo:
mov esi,!OBMain
cmp [wmsg],WM_DESTROY
je !wmDestroy
...
!DefWndProc:
invoke DefWindowProc,[!hwnd],[wmsg],[wparam],[lparam]
jmp !Finish


I had considered making this setting of the descriptor vars conditional based on whether or not it was already set. It takes about as much code to do the checking as it does to just reset it, and resetting it does no harm here.

Thanks,

Mike
Posted on 2004-06-28 22:05:13 by msmith
Hi msmith,

As far as I know, WM_GETMINMAXINFO will not be sent to any window on creation, and the order in which these messages are sent is undocumented, therefore unreliable. There's still the multiple windows problem. One way to do what you want is to maintain a set of window handles, and for each call of the window procedure, check whether the window is in the set - if not, add it. On window destruction you should remove the window from the set. This makes things quite slow compared to what they should be.

But why should you choose to work that way anyway? Why do you need a global variable before the window creation function returns?
Posted on 2004-06-29 04:50:39 by death
Hi Death,

First you say:

Hi donkey,
I believe you mean WM_NCCALCSIZE. It might send this message as well, but the first message I got when I created a window was WM_GETMINMAXINFO, and MSDN clearly states that it is being sent.

__________________
DEATH is a part of life


Then you say:


As far as I know, WM_GETMINMAXINFO will not be sent to any window on creation, and the order in which these messages are sent is undocumented, therefore unreliable.


What gives?

The code I posted actually works fine.



There's still the multiple windows problem.


Each window has its own WindowProc so there is no problem.


One way to do what you want is to maintain a set of window handles, and for each call of the window procedure, check whether the window is in the set - if not, add it. On window destruction you should remove the window from the set. This makes things quite slow compared to what they should be.

But why should you choose to work that way anyway? Why do you need a global variable before the window creation function returns?


I appreciate your help and advice (as well as others), but the structures for this compiler were designed long before this problem was uncovered and I am not rewriting the entire concept at this time. Thanks to you and others, i have found a good solution. Thank you,

Mike
Posted on 2004-06-29 09:25:12 by msmith
I also said (quoted):

For overlapped, pop-up, and child windows, CreateWindow sends WM_CREATE, WM_GETMINMAXINFO, and WM_NCCREATE messages to the window


That is, for windows that are not overlapped, pop-up, or child, MSDN doesn't say whether it sends WM_GETMINMAXINFO or not.
MSDN also doesn't say what order these messages come in. The order I posted came from my own experiments. That means, that no one guarantees you that order, now or in the future. I suspect that current versions of Windows send these messages in this order, but I cannot say that future versions will do so (especially for WM_GETMINMAXINFO being the first message).

If you want to put your trust in undocumented behaviour, go ahead and do it. I wouldn't in this case, and I have made a suggestion. As always, it's up to you to decide.
Posted on 2004-06-29 14:20:08 by death
yeah,it's good!
Posted on 2004-06-29 20:59:51 by bael2