How can the ID of a control that the cursor is passing over be returned? I have look for several hours and I have not found anything that works.

Thanks...
Posted on 2008-09-01 19:31:33 by green
Get the screen co-ordinates of the cursor, convert them to client co-ordinates, use RealChildWindowFromPoint to obtain the controls handle then convert it to an ID using GetDlgCtrlID...

invoke GetCursorPos, offset pt
invoke ScreenToClient, hwnd, offset pt
invoke RealChildWindowFromPoint, hwnd, offset pt
invoke GetDlgCtrlID, eax


For real time tracking you can use TrackMouseEvent.
Posted on 2008-09-01 23:17:48 by donkey
Thanks for the reply donkey, but I ran into a problem with RealChildWindowFromPoint in that it will not compile (error A2137: too few arguments to INVOKE). I checked user32.inc and found: RealChildWindowFromPoint PROTO :DWORD,:DWORD,:DWORD. I also looked at win32 API and it defines: HWND RealChildWindowFromPoint(HWND hwndParent,POINT ptParentClientCoords). What is the 3rd piece of data that MASM is looking for? I used NULL and it compiled and seems to work.
Posted on 2008-09-02 02:39:44 by green
Its a bug in user32.inc - change the prototype to only 2 dwords.
Posted on 2008-09-02 03:14:18 by Homer
Hi Homer, I tried changing the prototype and that fails on a compile because of the .lib; it would only accept NULL for the 3rd parameter and still compile. I have not been working with ASM long enough to know how to rebuild the library.

I would like to understand something that is apparently inherent to ASM and that is all code is wrapped into a rectangle - right???? Everything that requires attention including color has RECT connected to it.

I am attempting to change the color of a button using the control ID and there doesn't seem to be a way to do it. All I have found is references to the control's window and then use a rectangle to control the area where the button is located. If I am wrong, please tell me so, this is definitely a huge bug if it is true. All other languages have the ability of tracking the position of each control by its' ID.
Posted on 2008-09-02 07:19:01 by green
user32.inc is not wrong about this function. You don't pass an address of a point - you pass the whole point


local pt:POINT
...
invoke RealChildWindowFromPoint,hwnd,pt.x,pt.y


RECT is used everywhere, where rectangular stuff is managed :). Bitmaps, windows, regions.
I can't find a way to set the color of a button from another process. You can control directly only windows from your own thread. WM_CTLCOLORBTN
Posted on 2008-09-02 19:17:17 by Ultrano
Thanks Ultrano for the info on user32, my error by not looking into POINT struct. WM_CTLCOLORBTN is defined as: "The WM_CTLCOLORBTN message is sent to the parent window of a button before drawing the button."; otherwise, you can't change it on the fly as I am trying to do and I don't think I stated that directly in my post.
Posted on 2008-09-02 20:06:47 by green
You did state that in the post, and I noted that there's no (easy) way to change it on the fly for other processes/threads. If it's from your own thread, then you justsubclass (override the wndproc of ) the parent window, make the control redraw itself via InvalidateRect, intercept the wm_ctlcolorbtn, and provide a hbrush.
Posted on 2008-09-02 20:23:04 by Ultrano
For other processes, intercepting window-messages seems possible, with an external custom dll iirc. (just like how Spy++ does). It requires system hooks.
Posted on 2008-09-02 20:24:20 by Ultrano
I understand "invalidate rectangle" which I have used, but you are WAY over my head with "external custom dll iirc". Thanks to everyone, I think this one has drawn to an unresolvable conclusion. I would hope that someone that is more knowledgeable then me (not saying much) would write a macro for ASM that would fix this problem. I found many, many posts on this site relating to the issue of changing a push button face with a mouse event. Automation is a wonderful thing in the right hands and M$ is the wrong hands.
Posted on 2008-09-03 06:56:17 by green