FindWindow() issue

hello,

I'm using FindWindow() function to find a specific window/dialog.
as all the windows have the same name I can not use the Windowname in the function.
(if I use it, the function finds the first, while I need the third)
using a counter is not an option think of the possibility of next en back buttons
so I have to use the Classname arg., I think...
I know all the windows have static text items.
window 3 has 5 edit control boxes, I also know the ID numbers (Spy++ and Orca)
they are 1304 to 1308. So window 3 is Unique

how do I define the function, so it catches the 3 window?

regards,

ger

anybody...

regards,

ger

I guess if the windows have the same titles their classnames in most cases are also identical. So you can't use it to differentiate them.
It's hard to answer something without having enough information.
What's your "initial" problem? Why should you find this window?

The general strategy is to use all the criteria you can to get the window you need.

Here's what you have to work with:
1) The pid of the application. If you have launched the application, then you have its pid. The pid can be used to eliminate windows that aren't in the target application. Use GetWindowThreadProcessId to determine if a window is part of the target app.
2) Use the window title. If the title is constant you should always use it. If it changes then try to use a portion of the title that may not change. For example, the top level window title in the IE window I'm typing in is "CodeGuru Forums - Repy to Topic - Windows Internet Explorer". If I'm searching for this window, I know that the "Windows Internet Explorer" portion is constant so I can do a partial match for that.
3) Use the class name. The strategy here is similar to the title. Use the class name whenever possible and a partial match is better than nothing.
4) Search with the parent window. A good strategy is always supply a parent window handle with searching for a child window. This eliminates finding windows with the same title and class name, but have a different parent window.
5) Use all in combination. I usually launch the target application, store its pid, and then immediately find its top level window. I then use the top level window to build a hierarchy of windows as needed. That way all my child windows searches are performed using the hierarchy that I've built up. And because I've restricted the first top level window by the pid, I am ensured that I will only find windows in my application.

If the window you need cannot be identified solely by title/classname:
use EnumWindows(), and provide a callback to do whatever additional testing you need to identify the proper window.

EnumWindows() is what I would use in this case too.

While EnumWindows is a great choice for determining the top level window for an application, it's not very performant (because it enumerates all the windows on the system).

If you are trying to capture child windows of a specific window or dialog, FindWindowEx or EnumChildWindows will yield better performance.

Thank you guys for all the replies !!

to be more specific.
I made a program which calls at certain time an installer (Call of Duty -2-).
I use the call _spawnlp with the _P_NOWAIT option.
when dialog three shows up a serial has to be inserted.
using the Sleep(number) in combination with keybd_event('X', 0, 0, 0 )
I managed to insert the text.
but the Sleep() option is not waterproof!! (read poor programming)
so I need to capture the third window iso using a timer.
using PID is also difficult as the installer also creates new processses.
As all windows are using the same title "Call odf Duty 2" I can not differentiate on that,
however dialog three has 5 edit boxes. This an unique point as the installer will not
move on as long as the correct serail is not inserted.

is there a way to test on the existence of the edit boxes or on a part of static text?

I have also been testing with a program called AutoIt v3
it uses a call like
WinWaitActive("Call of Duty(R) 2","The Key Code is loca")
to find the requested window/dialog.

I will have a go with the posted suggestions

regards,

gerwin

You can use EnumChildWindows to enumerate all the child windows of a given top level window.

Then you can use GetDlgItem to find a specified control in a window. That function requires the identifier of the control. You can find that identifier using the Spy++ application.

Note that the identifier is a constant and will have the same value every time you run the application. So you need to find it only once, then you can hard code the identifier in your application.

Quote:

---

Originally Posted by srelu

Note that the identifier is a constant and will have the same value every time you run the application. So you need to find it only once, then you can hard code the identifier in your application.

---

Not necessarily. It is not a constant. It may be defined as constant in a code but ID of any window can be changed on the fly by the application’s code.

this should to the trick

PID = _spawnlp(_P_NOWAIT,"C:\\COD2\\COD2DVD\\setup.exe"," ",NULL);
lhwnd = NULL;
lhwnd_test = NULL;
while (lhwnd == NULL)
{
lhwnd = FindWindow(NULL, L"Call of Duty(R) 2");
if (lhwnd != NULL)
lhwnd_test = GetDlgItem(lhwnd, 1304);
if (lhwnd_test == NULL)
lhwnd = NULL;
Sleep(100);
}

any finetuning comments

regards.

ger

Are you trying to break this game's registration by brute force?
First, this is illegal.
And second, this is stupid.

P.S. Your original post smelled like a cheat; didn't want to say anything until I was sure.

P.P.S. This forum used to be full of interesting questions / answers. Now it mostly has requests from kiddie hackers (who haven't mastered "Hello World" yet) or homework assignment... That's a shame.

Virus and anti-virus technology, we need to study them. Just not do bad things on the list.

Understand that on this forum, we are if violation of the AUP if we answer any virus related questions.

A lot of legitimate stuff can be virus related.

I find myself spending more and more time into projects that need me to interface to other programs, often programs that weren never intended to be interfaced to. So I tend to need a lot of low level stuff that could just as easily be used maliciously.

Even stuff like this very question. Automating/scripting an installation that hasn't got provesions for it is part of the common problems I'm needing to solve. There's a thin line between filling in a known registration key and filling in a registration key at random trying to break a code. All of the code would be the same except for 3 or 4 lines of code.

Quote:

---

Originally Posted by legendsoft

Virus and anti-virus technology, we need to study them. Just not do bad things on the list.

---

Study viruses as much as you want.
But what does it have to do with repeated attempts to break a password to a commercial game?
I understand the need for automation. So find a free app and play with its installer!

guys guys,

NO I'M NOT BREAKING THE SERIAL GAME OR ANYTHING OF THIS KIND !!!!!
AND NO I"M NOT COOCKING A VIRUS !!

I onw the complete COD Collection.
recently I bought an Blue ray recorder and I want to put the complete set on a BD
I want to make an auto start menu to install or play the game.
my own serial(s) will be auto inserted.
and the menu based program will not go public.

as shame my post has to end this way.

regards,

gerwin

Quote:

---

Originally Posted by TBBW

I onw the complete COD Collection.
recently I bought an Blue ray recorder and I want to put the complete set on a BD
I want to make an auto start menu to install or play the game.
my own serial(s) will be auto inserted.
and the menu based program will not go public.

---

If it won't go public, why do you need to remove the serial # entry step from the installer?

From what I can tell. he never asked or mentioned that.
He wants to identify the specific screen with the request for the serial on it so he can SendInput() his known serial number to it.

It's what automation like this does. it does the boring chore of typing those annoyingly long serial keys yourself.

Quote:

---

Originally Posted by OReubens

It's what automation like this does. it does the boring chore of typing those annoyingly long serial keys yourself.

---

My point was, is he installing Call Of Duty very frequently? If not, why go through the trouble of automating it? If he is installing COD frequently, then...why? Generally, you install a game on your computer & you don't have to do it again unless you re-install the OS or get a new computer.

Quote:

---

Originally Posted by TBBW

guys guys,

NO I'M NOT BREAKING THE SERIAL GAME OR ANYTHING OF THIS KIND !!!!!

---

I apologize if I’ve jumped to a wrong conclusion.
I am not a game player, and I do not understand the need for frequent installation of a game.
In any way, it looks like you are choosing an awfully complex way to solve what appears to be a not-so-big issue.

oke, two more questions to answer.
why automate this, well basically not speed up the process (developing my menu
program takes more time than typing the serial) but for the FUN and LEARNING
why not use an menu creator, I tried AutoPlay Media Studio and AutoIT.
AMS came closes to what I want...
AutoIt is, in my opion, unstable.

so back to my question.............

I made:

PID = _spawnlp(_P_NOWAIT,"C:\\setup.exe"," ",NULL);
lhwnd = NULL;
lhwnd_test = NULL;
while (lhwnd == NULL)
{
lhwnd = FindWindow(NULL, L"Call of Duty(R) 2");
if (lhwnd != NULL)
lhwnd_test = GetDlgItem(lhwnd, 1304);
if (lhwnd_test == NULL)
lhwnd = NULL;
Sleep(100);
}

any comments/ fine tuning

regards,

ger

ps, how do I posts the code more readable..

Quote:

---

Originally Posted by TBBW

ps, how do I posts the code more readable..

---

Use code tags (surround your code with [ CODE] [/ CODE] minus the spaces). Go back an edit your code - you'll see that I've added code tags.

As far as your code, I would use CreateProcess to start setup.exe rather than _spawnlp. This would allow you to retrieve the process id.

From there you can use the pid to restrict looking for windows only in your process. You can use EnumWindows as I've explained earlier to get the top level windows and GetWindowThreadProcessID to find the top level window for the setup.exe process.

From there you can find any window in your process from the top level window. I've explained all this in post #4. To identify a dialog with 5 child edit windows, get the top level window, use FindWindow with the class name, title and parent hWnd. Once you have the dialog, then use FindWindowEx with the parent dialog hwnd and the class of "EDIT". You keep calling FindWindowEx in succession, the first time passing in the parent hWnd, and each subsequent time passing in the hWnd to the edit box you've found. When you've found 5 of them on a single dialog you know you have the correct dialog.

You had mentioned earlier that setup spawns multiple processes. You can handle this scenario by tracking the running processes. What you do is get a list of running processes, and flag all these processes as base processes. Then you start your test application and periodicly update the process list. Any new processes will be processes that you've created (directly or indirectly). Since it's helpful to always have the top level window as a starting point, you generally want to retrieve the top level windows for each process in the list - that way you can use it later if you need to.

This may sound like a lot of work, but it isn't too bad. Take a look at the ModuleTest.zip file in my reply here: http://www.codeguru.com/forum/showthread.php?t=440881

Pretty much all the code is there that snaps the processes and retrieves their top level windows.

@ Arjay

Thanks for the reply, found he zipped file, will have a look!!

regards

ger

Considering all, I think I would vote for windows hooking - global CBT hook.

To JohnCz

Would you be soon kind to tell me some more over window hooking.

regards,

ger

The idea is to write an application and DLL that will establish a global WH_CBT hook to monitor activation of windows. I presume windows you are interested in are dialogs. Pass handle of a window you want to be notified to a DLL and start a hook. After launching this app, start program as usual, using OS rather than launching it from your app.
Hook can check if window class matches dialog class and notify your application about this, using custom message and passing handle to activated dialog.
Your application can use this handle to determine if dialog is the one you are looking for, using known control class (edit) and 5 control’s IDs.

This hint should get you started. Lookup MSDN for SetWindowsHookEx or search this forum about posts or articles about hooks.

Had a look on the create process option and the hook option.
the hook option is, at this moment, out of my leauge.
the create process works more or less the same as the spawn option.

I think my code is not elegant, but it is robust and works for me.
there is only one think left, if you cancel the setup.exe, the while loop
will never end.
so I tried a scond test, see if the process is still there (GetProcessID()).
it does not work, I'm doing something wrong.
is there a simple test (one liner) to check if the process is still active
like:

Code:

---

while ((lhwnd == NULL) && (PID != NULL))

---

I know the PID and also the full name setup.exe

regards,

ger

Why don't you post more of your code? That way we can see what you are actually doing.

as requested the piece of code.
I use the comment // to play between diff. options

Code:

---

.
.
.
PID = _spawnlp(_P_NOWAIT,"C:\\COD2\\COD2DVD\\setup.exe"," ",NULL);

// CreateProcess(L"C:\\COD2\\COD2DVD\\Setup.exe",
//                          L" ",
//                          NULL,
//                          NULL,
//                          FALSE,
//                          0,
//                          NULL,
//                          NULL,
//                          &si,
//                          &pi);

lhwnd = NULL;
lhwnd_test = NULL;
CHECK_PID = GetProcessId(pi.hProcess);
                                                                                                                                               
while ((lhwnd == NULL) && (GetProcessId(pi.hProcess) != 0))
{
        lhwnd = FindWindow(NULL, L"Call of Duty(R) 2");
        if (lhwnd != NULL)
                lhwnd_test = GetDlgItem(lhwnd, 1304);
        if (lhwnd_test == NULL)
                lhwnd = NULL;
        Sleep(100);
}                                               
                                               
// if (lhwnd != NULL)
Send_Key();

_cwait(NULL, PID, NULL);

// WaitForSingleObject( pi.hProcess, INFINITE );
// CloseHandle( pi.hProcess );
// CloseHandle( pi.hThread );
.
.
.

---

the while loop works perfectly, as long as the user does not abort the setup.exe using the
cancel option, the loop will be infinite.
so I need a second test, see if the process is still running.
I have all the process data, so it should be possible.


regards

ger

Use CreateProcess instead of spawn. Then use hProcess and GetExitCodeProcess api to detect if the process is still running. Check the exit code against STILL_ACTIVE to find out if the process is still running. Another way to check if the process is still running is to call:

Code:

---


BOOL bRunning = ( WaitForSingleObject( hProcess, 0 ) == WAIT_TIMEOUT );

---

To Arjay,

works fine now !!
but
just to be curious;
why createprocess iso spwan?

regards,

ger

CreateProcess has more startup features and returns the process id, the thread and process handles, and much more. CreateProcess also works for ANSI and UNICODE.