FindWindow() issue

[VladimirF]

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!

[TBBW]

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

[Martin O]

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?

[OReubens]

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.

[Martin O]

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.

[VladimirF]

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.

[TBBW]

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

[Arjay]

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.

[TBBW]

@ Arjay

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

regards

ger

[JohnCz]

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

[TBBW]

To JohnCz

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

regards,

ger

[JohnCz]

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.

[TBBW]

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:

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

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

regards,

ger

[Arjay]

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

[TBBW]

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

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