Simulate mouse hover in windows application using win32 api - winapi

With a game application (may have been minimized or hidden), I have a button that only shows up when I hover over it. I need to write an script (by c# or python) that can click that button without moving my cursor. I was able to simulate click event with SendMessage(hWnd, WM_LBUTTONDOWN, ...), but i don't know how to make that button show up.
I have seen a tool that can do it, I don't know how they do it.
My problem seems similar to this problem.
I won't need SendInput or mouse_event because it will move my cursor.
Any one can help? Is there another unrelated way?

Related

How to prevent mouse click event on Windows

I record the mouse events on windows by using robotgo package. Package provides to get bitmap of clicked area but the latency of having bitmap is super sensitive situation here.
For example:
If I click any checkbox which is unchecked on the screen, provided bitmap must contains the state of unchecked but it provides me checked state and cannot simulate it with robotgo or cannot trigger click by using bitmap.
Solution to this scenario is that I need to prevent windows mouse click event until bitmap provided by the package (or adding some delay for click event) then trigger the click event on windows.
I made some research online but couldn't find a proper solution. How prevent click event on Windows in Go? Is it possible or is there any other way to make it happen?
A low-level mouse hook can eat mouse events. SendInput can generate mouse input events.
You would have to set a flag somewhere so you don't eat your own fake input events.
Keep in mind that SendInput is not perfect (can be detected by other hooks) and playing with the input system like this is usually not the best solution. Adding 500ms (or some other delay) to every mouse click is going to be very annoying for your users.
It is better to use UI Automation to get information about UI element states in other applications...

Why don't background windows receive mouse events when I drag off the foreground window?

When I click on a non-reactive area of a win32 window in the foreground (for example, a blank space on a menu bar) and drag the mouse off, background windows do not receive mouse events. Buttons don't got into hover state, the cursor doesn't change, etc. The mouse is "captured" by the foreground window, although it doesn't receive messages either unless the mouse is over it. This state persists until I release the mouse button. Why is this, and how can I get out of this state programmatically without releasing the mouse button?
Researching this issue, I thought at first it was related to the concept of mouse capture, but it appears it is not. GetCapture() returns NULL during this state, whatever it is.
Clarification Edit: This is easy to see in the simplest of applications. Create a new Win32 project in Visual Studio with the default project template, which makes an empty window. Run it, and click and hold the blank inside of the window. Drag the mouse outside the window, and note that no buttons in background windows light up or otherwise respond to mouse-over events. Even if I stick ReleaseCapture() in the WndProc so that it fires after every message, the result is the same. It really seems like this has nothing to do with mouse capture in the Get/SetCapture sense.

Hidden window takes all input

I have other application's fullscreen direct-x window, which I need to hide. I found the way to hide it by hooking direct-x create device and changing window parameters so it is not fullscreen. This works ok on XP but on Win-7 I can't use any other application because it looks like application is switching it to be foreground window so all clicks and keyboard input goes to that window. However if I click fast I can make some action. This make me think that this app is using some function to direct input to itself, or to focus, dunno what.
The other thing is that if I resize the window and don't hide it, all works ok.
I tried to hook SetCapture, SetForegroundWindow, SetActiveWindow and SetWindowPos and none of this helped.
Do you have some idea how can I hide window in other way, or what can cause this focusing to invisible window?

Only allow one NSWindow to be selectable until action is completed (Cocoa)

I have a program with many windows open. I want all windows to be visible, but only one window can be interactable, until a certain event has occured. e.g. pressing a button.
At the moment, I can still click another window, and interact with it, how do I only allow interaction with ONE window, until a certain event occurs?
Imagine this as the program:
I want only the frontmost Window to be selectable, if I try to select any of the other windows behind it, it should not work.
Does anoybody know how to do this?
Thanks!
Michael
It sounds like you want a modal window.

Borderless Taskbar items: Using a right click menu (VB6)

Even when BorderStyle is set to 0, it is possible to force a window to show up on the taskbar either by turning on the ShowInTaskbar property or by using the windows api directly: SetWindowLong Me.hwnd, GWL_EXSTYLE, GetWindowLong(Me.hwnd, Win.GWL_EXSTYLE) Or Win.WS_EX_APPWINDOW. However, such taskbar entries lack a right-click menu in their taskbar entry. Right-clicking them does nothing instead of bringing up a context menu. Is there a way, to attach a standard or custom handler to it?
Without a hack, I think you're going to be stuck here, I'm sorry to say. When you set the VB6 borderless properties, you inherently disable the control menu. The control menu (typically activated by right-clicking the title bar of a window or left-clicking the icon in the upper left) is what's displayed when you right-click a window in the task bar.
Now, if you're in the mood to hack, you might be able to "simulate" the behavior in such a way that the user doesn't know the difference. I got the idea from this message thread on usenet.
Basically, it sounds like you may be able to hack it by using two forms. One form is minimized right away, and becomes your "stub" in the task bar. The other form is the one you're currently designing (which we'll call the "main" form). The stub form is what actually loads and displays your main form.
The stub form isn't borderless, and must not deactivate the control menu. It is positioned off screen and at the smallest possible size. You'll respond to its form-level events, and then use those to communicate the appropriate behaviors to the borderless form.
That's the general gist of the hack. If I wasn't at work right now, I'd whip up a simple VB6 project and see if I could get it to work for you.

Resources