include "WIN32AX.INC"

;;; Diablo player name dialog windows' hierarchy:
;;; Main window (class: "DIABLO"; title: "DIABLO")
;;;     owned popup dialog (class: "SDlgDialog"; title: "")
;;;         owned popup dialog (class: "SDlgDialog"; title: "")
;;;             child custom edit control (class: "DIABLOEDIT"; title: <player name>)

        .code
start:  invoke  FindWindow, dword [esp], "DIABLO"
; enumerate top-level Diablo windows to find second-level dialog
        invoke  EnumThreadWindows, <invoke GetWindowThreadProcessId, eax, NULL>, SetDiabloPlayerName, eax
        ret

proc SetDiabloPlayerName, hwnd, hwndMain
; check that hwnd owner's owner is Diablo's main window
        invoke  GetWindow, [hwnd], GW_OWNER
        test    eax, eax
        jz      .continue
        invoke  GetWindow, eax, GW_OWNER
        cmp     eax, [hwndMain]
        je      .found
.continue:
; not our dialog, continue enumeration
        mov     eax, TRUE
        ret
.found:
        invoke  FindWindowEx, [hwnd], NULL, "DIABLOEDIT", NULL
        mov     [hwnd], eax
        invoke  SendMessage, eax, WM_SETTEXT, 0, "bald"; WM_SETTEXT is synchronous
        invoke  PostMessage, [hwnd], WM_CHAR, ('r'), 0
        invoke  PostMessage, [hwnd], WM_KEYDOWN, VK_RETURN, 0x1C0000
        invoke  PostMessage, [hwnd], WM_KEYUP, VK_RETURN, 0xC09C0000
; stop enumeration
        xor     eax, eax
        ret
endp

        .end    start    

The problem is that most windows don't have title or unique window class.

Azu,

You don't have problems with getting handle to window that will get focus upon activation? I mean, when window is still inactive?

Azu: In my experience with sending keystrokes I found that each program has it's own way of dealing with keyboard input. You will have to customise your code for each program you want to inject into.

When activating windows you generally only need to activate the parent and Windows (with a capital W) will then also activate the child windows that are on top of the parent. It is sometimes the case that you cannot easily distinguish between child windows by window name or class name and thus you may not be able to figure out which window is receiving the keyboard strokes. For simple programs like Notepad that never open more than one child window your task is easy, but other programs may not be so friendly. Some programs don't even run the message loop so trying to send WM_* messages into those programs will have no effect at all. Some programs run the message loop but ignore all keystrokes and use other methods to detect which keys are pressed, so again, putting keystrokes into those programs will have no effect at all. Do you see the problem?

I don't even know which function to use now.

Azu wrote:

I don't even know which function to use now.

It's not a matter of choosing the right function. It is a matter of finding out what each program uses to detect keystrokes and using the appropriate methods to simulate key presses. Note: I said use "the appropriate methods" and not use the appropriate function, the difference is that some programs require complex things to be done to get the simulation working. Sometimes using one single function will not be sufficient.

If there is something I have to do per program to find out what method or whatever to use, why can't a function be made to do that instead of me donig it? I don't understand =/