get handle of dialog at WM_INITDIALOG time

[Jimg]

When writing a general purpose/reusable proc, is there any way for the proc to get the handle of the dialog that made the call to the proc without the caller having to pass the handle in the call?

GetActiveWindow only works after the window is on the screen, not at WM_INITDIALOG time.

[donkey]

Pass the handle of the dialog as a parameter in the procedure.

[Grincheux]

Try with GetParent

[donkey]

Try with GetParent

GetParent requires the handle of a child control, he would need the handle of the parent to find the child handles which might not be available in the procedure he is calling.

[Jimg]

So, basically, the answer to my original question is "no".

[sinsi]

Funnily enough, I saw some source code recently where they solved this problem by using EnumWindows and searching for their title  :bdg
I guess the answer is "no" too.

[drizz]

I remembered seeing in olly DCBAABCD pushed before window proc, and allways wondered what it could be used for...

..Idea!  :8)

Code Select Expand


; setup seh!
mov edi,esp
mov eax,0DCBAABCDh
or ecx,-1
repne scasd
mov eax,[edi+6*4];; hWnd
mov eax,[edi+7*4];; uMsg
mov eax,[edi+8*4];; wParam
mov eax,[edi+9*4];; lParam


according to Raymond it's for stack check http://blogs.msdn.com/oldnewthing/archive/2004/01/15/58973.aspx :

The window procedure

So many people misdeclare their window procedures (usually by declaring them as __cdecl instead of __stdcall), that the function that dispatches messages to window procedures contains extra protection to detect incorrectly-declared window procedures and perform the appropriate fixup. This is the source of the mysterious 0xdcbaabcd on the stack. The function that dispatches messages to window procedures checks whether this value is on the stack in the correct place. If not, then it checks whether the window procedure popped one dword too much off the stack (if so, it fixes up the stack; I have no idea how this messed up a window procedure could have existed), or whether the window procedure was mistakenly declared as __cdecl instead of __stdcall (if so, it pops the parameters off the stack that the window procedure was supposed to do).

[gwapo]

Hi Jim,

When writing a general purpose/reusable proc, is there any way for the proc to get the handle of the dialog that made the call to the proc without the caller having to pass the handle in the call?

If you are working on a modal window, then a call to GetForeGroundWindow will give you the handle of the current (and hopefully the one who called your reusable proc) window.

However, that's not safe because the user can activate other window at anytime your procedure is running.

Why not just pass the handle of the window to you procedure? I think it's the safest way.
Maybe it's not related, but you can check my implementation of message cracker, I am passing the handle of the calling window to all procedures attached to WndProc: http://www.masm32.com/board/index.php?topic=3880.0

Cheers,

-chris

[Jimg]

Hi Drizz-
Amazing what knowledge you dredge up.  Not something I would do in a supposedly bullet proof app, but very interesting.

gwapo-  I just tried it, and I get a different handle using GetForeGroundWindow.  The problem is that the window isn't actually up yet at WM__INITDIALOG time.

[gwapo]

I just tried it, and I get a different handle using GetForeGroundWindow.  The problem is that the window isn't actually up yet at WM__INITDIALOG time.

Well, even if the window is not up yet, you can still get the *active* window from the GUI thread information. Try it if this is what you need:

Code Select Expand


GUITHREADINFO struct
    cbSize dd ?
    flags dd ?
    hwndActive HWND ?
    hwndFocus HWND ?
    hwndCapture HWND ?
    hwndMenuOwner HWND ?
    hwndMoveSize HWND ?
    hwndCaret HWND ?
    rcCaret RECT<>
GUITHREADINFO ends

.data
guiInfo GUITHREADINFO<>

buffer db 32 dup(0)

.code

; assuming this code is running inside your generic proc:
invoke GetGUIThreadInfo, NULL, addr guiInfo ; pass NULL for thread ID, because I want the current running thread

; In here, the structure is filled with the information you need:
mov eax, guiInfo.hwndActive
invoke dwtoa, eax, addr buffer
invoke MessageBox, 0, addr buffer, NULL, MB_OK



Hope this helps,

-chris

[Jimg]

Thank you.