Hello Everybody

Do anyone know how to press a button in another process. I know how to press a button in my own app. It seem that you must use an equate of that button in your own process or another app that you build.


Example:
invoke GetDlgItem, buffer1, equ_100
mov Auto_Click, eax

Invoke SendMessage, Auto_Click, WM_LBUTTONDOWN, 0, 0
Invoke SendMessage, Auto_Click, WM_LBUTTONUP, 0, 0
Invoke SendMessage, Auto_Click, WM_LBUTTONUP, 0, 0
Posted on 2002-11-26 19:25:21 by cmax
Findwindow, FindwindowEx will be the main api you need to look into.


FindWindow, "SciCalc", "Calculator"
FindWindowEx,eax,NULL,"Button","7"

That would get you a handle(hwnd) to the 7 on windows calculator.

Now you just need to send the messages.
Posted on 2002-11-26 19:59:20 by Betrayed
I never did understand the FindWindowEX. Going to read the API help file now.

Thanks alot Betrayed
Posted on 2002-11-26 20:43:28 by cmax
I got FindWindowExA to work. Come to I think of it i got it to work a very long time ago but gave up because i never could do the button click. One thing for sure i know how to do it by nature now. :)

The main problem i think is how to get the identifier. The help files say something like this:

*You MUST specifies the identifier of the control to be retrieved*

If that mean EQUATE it make me realize that all programs don't have to use them. Then if they do how are you suppose to find it.... I use GetSet, MS Spy and a few other all night and i could not find anything but handles and such.... I'm sure i over looked something because i can't find what to look for :( Do anyone know how to get the unick identifier for an control not in your process...
Posted on 2002-11-27 06:06:14 by cmax
If I recall correctly, windows calculator's buttons are ownerdrawn...
It is probable that FindWindow won't find them...
The best way for calc is maybe to activate the window and simulate key pressing using keyb_event()...
Posted on 2002-11-27 06:11:22 by JCP
Afternoon, cmax.

GetDlgCtrlID possibly?

Cheers,
Scronty
Posted on 2002-11-27 06:15:17 by Scronty
This is the kind of thing that made the API help files so hard to understand and that why i never really got into it until recently.... It tell you what you MUST have but it never tell you how to go about getting your MUST HAVE.

I mean how long would it take a nebie to learn that ownerdrawn may not be founded and that it's time rig something up like Key_Events. May be GetDlgCtrlID will work if it has one. I hope this will do it or else i have to use an Ancient way of doing it. I Did it with Screen Size, Resolution and Mouse_Event than i got the courage to come to the board and ask for a better way. Now i finially learn that something we still just have to Rig Stuff Up just like a kid with a cho-cho-train.

Thank God for the Win32ASM Community messageboard or there would be no ME and my ASM.



Thanks Guys now i see the Big Picture
Posted on 2002-11-27 11:24:02 by cmax
But you know i do, so I would like to say Mission Near completed and IS understandable, but Please Beam me BACK Up Scotty, i can't take no MORE.

Thank You

Guest what all, I got all THREE handles successfully and would you know it, it still did not work... At lease for the outside Application that i am trying to press the button on, but it may work for something more simpler, *MAYBE*.

Than I read the BOTTOM LINE in the help file for the GetDlgCtrlID and this is what it say.

Thanks again "Although GetDlgCtrlID may return a value if hwndCtl identifies a top-level window, top-level windows cannot have identifiers and such a return value is never valid. "

Heck, it did not EVEN work when i made the Window stay Under all other WINDOWS...

Seem that this means * USELESS *

I think this is all about protection of a Window with-in a system for other purposes. so i forgive BILL again but i loss 36 hours with little sleep B I L L. I must be going crazy.

I guest back to the cho-cho TRAIN for me. Strange but true... This stuff is more than just educationable, it's a heck of a challenge but still fun as HELL . And to think some people get pay for it.

A question to Readiosys:

Even tho i know how to do it with Mouse_Event. The problem is it has to use a LOT of code if i want to make it work for ALL monitor size so while thinking about all of this i realize that your Key_Board_Event is the solution because it would require only one set of code to handle ALL.

this is the way i learned to do it:

.data
x_hWindow dd 316 ; from left
y_hWindow dd 65 ; from top


.code

PUSH TRUE
PUSH 600
PUSH 800
PUSH 0
PUSH 0
PUSH hWindow
CALL MoveWindow

invoke SetCursorPos,x_01,y_01
invoke mouse_event, MOUSEEVENTF_LEFTDOWN, 0, 0, 0, 0
invoke mouse_event, MOUSEEVENTF_LEFTUP, 0, 0, 0, 0

I force the Window to be at a point than i measure all button positions to be ready for the clicks POSITION.
How Crude :( .... got to do it for ALL Res and Monitor sizes but it's better than nothing if i don't find a real way of doing it.

I think KeyBoard_Event make more since. Could you please direct me to the sample that explains how.

I am prepared to do the whole 48 hours to get this job done.... I usually win out and but this one is wearing me out. I can't never sleep until i fall out if i don't see the LIGHT once i get stumped by something.

Well this is all what is on my mind, I hope i did not miss a WORD :) :) :)
Posted on 2002-11-27 14:10:10 by cmax
Hi Cmax,

This looked like fun so I put together a little virtual keypad that uses EnumChildWindows, with FindWindowEx in the Callback proc, to enumerate all the Button controls in SciCalc. The hwnds are stored and when the matching button is pressed in the virtual keypad it sends the WM_LBUTTONDOWN/UP messages to the appropriate control hwnd in SciCalc. To match up which handle goes with which control you just need to do a bit of, er, exploration with your favorite debugger and Message monitor to determine the order in which the controls are created. The Enum proc cycles through the Button controls in the same order they were produced.

The example app only has some of the buttons enabled, but the skeleton is there for duplicating the entire SciCalc interface, including the complete hWnd structure so you don't need to do the debugger bit. I think this should avoid any compatibility problems because the absolute mouse position is never used.

Cheers,
Kayaker
Posted on 2002-11-27 23:27:22 by Kayaker
A few suggestions.

Your proggy will not work on localized versions of Windows, because of window name.
Use only class name.
invoke FindWindow, ADDR SciCalc, NULL
By enumerating buttons you have to check the text of the button,
because you are not guaranteed the order of the buttons under different versions of Windows.
Posted on 2002-11-28 04:13:58 by Four-F
Kayaker,

That is a Super Idea. I don't know what to say but Z a m m m , you put the F and I back in Programming.
(fun and intrestest)

Also Four-F must be right because it's not working on Win95 and that the only one i have right now. But it seems very easy to follow so i will find a way.

Thanks alot :)

PS: Posted on 2002-11-28 08:17:14 by cmax
Hi

It's probably not a bad idea to drop the lpWindowName of FindWindow since it's a bit redundant anyway since the lpClassName of "SciCalc" is so unique, but in general terms I don't see how it wouldn't work with any unmodified version of Windows calc, as long as the windows title is still "Calculator".


<<By enumerating buttons you have to check the text of the button, because you are not guaranteed the order of the buttons under different versions of Windows.

That's a good point, but how do you check the button text of an ownerdrawn control in another process which uses LoadStringA and DrawTextA to draw the button text, as SciCalc does?

GetWindowText "cannot retrieve the text ... in another application" and GetDlgItemText or sending WM_GETTEXT to the control also fails.


It appears that DrawTextA is called as part of an UpdateWindow (WM_PAINT) call after all the controls are produced and the window is just about to show. (An API monitor helps here) You can see a series of calls similar to this one which is about to draw the "7" button text. It's possible you could do some wizardry to match up the button handle with the string value runtime, but once calculator is open I think you're stuck.

DefWindowProcA
HWND:000006C0 \\ hWnd ; SciCalc
DWORD:00000135 \\ Msg ; WM_CTLCOLORBTN
DWORD:00000772 \\ wParam ; device context
DWORD:000007CC \\ lParam ; hwnd of button

DrawTextA
HANDLE:00000772 \\ hDC
LPSTR:005000B2:"7" \\ lpString
DWORD:FFFFFFFF
LPDATA:0056FAF0
DWORD:00000025


So, while it's a good point that doing a programmatic check of which text string goes with which button hwnd, I don't know if it's possible in a simple way.

Kayaker
Posted on 2002-11-28 16:21:07 by Kayaker
I don't see how it wouldn't work with any unmodified version of Windows calc, as long as the windows title is still "Calculator".
Windows title is still "Calculator" only under English Windows.
I have localized Russian version. And my calculator's caption is "???????????" ;)

but how do you check the button text of an ownerdrawn control in another process

Didn't think about it. Yes it's not easy, but anyway under my w2k+sp2 your prog press quite different buttons on my calc.

BTW, TaskManager shows me that your VirtualCalc.exe loads CPU up to 99% ;(
Posted on 2002-11-29 03:44:57 by Four-F

Windows title is still "Calculator" only under English Windows.
I have localized Russian version. And my calculator's caption is "???????????" ;)

Lol, good point, I never even thought about that. Good thing I don't do this for a living :grin:

One thing is that it was designed for calc to be in Standard mode not Scientific else it will push the wrong buttons, and the order of hwnd creation is based on Win98SE. The Win2K version certainly could be different (though I didn't think MS would've rewritten little 'ol calculator ;-), but that could be due to localized language versions as well.

As for the CPU loading, that's totally bizarre. Is this just when loaded up? If you look at the code there's absolutely nothing there to load the system (the wonderful thing about ASM), and on mine it doesn't even register. It might be due to EnumChildWindows getting caught in a loop, but again, I had no problems with Win98SE and visually traced the code the entire way.

Just goes to show the difficulties in playing with processes other than your own :tongue:

Kayaker
Posted on 2002-11-29 10:00:23 by Kayaker
Hi Kayaker

I don't Believe it. It Works. I forgot about what i wanted to use it for and got hung up on the Cal. So I use it with an Icz sample app and it work perfectly. Thanks for solving this major problem for me. I could have never done it on my own. You see above what i was going to resort to. Now i can move on.


Four-F, I use Win95 and i don't think Taskman.exe is the same as TaskManager in newer Windows. Would you or someone know where i can find such a tool that can tell how much is loaded on the cpu.

Thanks
Posted on 2002-11-29 19:54:14 by cmax
cmax,

Try:

START

PROGRAMS

ACCESSORIES

SYSTEM TOOLS

SYSTEM MONITOR

This works on my Win95

farrier
Posted on 2002-11-30 00:57:01 by farrier
Kayaker: ...it was designed for calc to be in Standard mode not Scientific...
OK. It works properly in Standard mode.

Kayaker: As for the CPU loading, that's totally bizarre.
The trouble is here. Don't do this:

	.ELSEIF uMsg==WM_CLOSE

invoke EndDialog, hWnd, 0
.ENDIF
ret

DlgProc endp


	.elseif uMsg==WM_CLOSE

invoke EndDialog, hWnd, 0
.else
xor eax, eax [color=blue][b]; return FALSE[/b][/color]
ret
.endif

mov eax, TRUE [color=blue][b]; return TRUE[/b][/color]
ret

DlgProc endp


cmax: Would you or someone know where i can find such a tool that can tell how much is loaded on the cpu.
TaskInfo
Posted on 2002-11-30 04:01:51 by Four-F