I'm working on a screen capture utility that captures active windows. I'm using transparent overlays to capture the full screen and then overlay the active windows based on mouse move events passed through to the underlying desktop/windows.
Both of the overlay windows currently use the WS_EX_TRANSPARENT style to allow mouse events to pass through to the underlying windows so I can detect where the mouse cursor is located. I grab the window handle and rect size to outline the window and then use Global Mouse and Keyboard Hooks to accept or reject a capture.
It's pretty ugly and spread out code (which is why I'm not posting here for now) but it all works very well and I can highlight the windows in mousemove and capture clicks with the global mouse and key handlers.
It all works except for this problem:
The Global Windows Hooks do not fire over an Admin Window so when I want to capture a Powershell, Command or Visual Studio (in Admin mode) Window no hook events are forwarded.
Apparently there's no way to work around this security issues using Windows hooks (or GetAsyncKeystate() for that matter).
I've tried a couple of different approaches to work around this issue:
Instead of using Hooks I tried using the highlight window to capture mouse/key events
This sort of works, but it's clumsy - fails if no window is selected at all (no way to get out) and doesn't allow for selecting contained windows once the parent is selected (ie. no drill down)
I also tried Win32 GetAsyncKeystate() which captures the last mouse or keyboard input and that would work, but it too fails to send mouse or key interactions from Admin windows.
So I have two choices imperfect solutions at the moment: using Hooks or GetAsyncKeyState to get the proper Window browsing selection behavior for all but admin windows, or I can capture all windows but lose the ability to drill into child windows after a parent window is selected.
I'm at the end of my rope and the real question is this:
Is there some way to create a semi-transparent or transparent window that can intercept mouseclicks and pass them on to the window area below?
Related
I want to create a WPF window that will display on a touch sensitive screen and the window contains 80 buttons. I want my WPF app to recognize tabs on specific buttons. Do I need any specific API to do that or how will the tabs on the touch sensitive screen be transmitted to my WPF app?
Any suggestions?
Thanks
Windows 7 and its higher versions have the ability to receive input from multiple touch-sensitive devices. WPF applications can also handle touch input as other input, such as the mouse or keyboard, by raising events when a touch occurs.
WPF exposes two types of events when a touch occurs − touch events and manipulation events. Touch events provide raw data about each finger on a touchscreen and its movement. Manipulation events interpret the input as certain actions. Both types of events are discussed in this section.
WPF enables applications to respond to touch. For example, you can interact with an application by using one or more fingers on a touch-sensitive device, such as a touchscreen This walkthrough creates an application that enables the user to move, resize, or rotate a single object by using touch.
Source MSDN : https://msdn.microsoft.com/en-us/library/ee649090.aspx
Also read this codeproject article - http://www.codeproject.com/Articles/692286/WPF-and-multi-touch
WPF applications work on the touch screen without any needs for modifications. Of course you can add support for gestures like pinch-zooming etc. but tapping on buttons works out of the box. For the WPF application it doesn't matter if user is tapping with the finger or clicking with the mouse.
I am currently working on a desktop C# WPF application where the goal is to make it look and feel like a "real" Windows Store App.
I want to add an appbar that should be shown when the user swipes up from the bottom. To do this in a normal app you just position your finger outside the screen area, and swipe up.
But if I do that in a fullscreen WPF program I don't receive any TouchDown or TouchMove events - probably because the finger is already down when entering the actual screen area.
I have tried with the Manipulation framework also, but same result here. Even when I hook directly into the message queue using WndProc or other hooks I get no events at all.
The funny thing is that I can see the "touch cursor" move around the screen, so at least something in the underlying framework is notified.
Does anyone have an idea how to do this?
p.s. It is not an option for me just to use a windows store app instead, because of hardware connectivity issues ;-)
You will need to keep track of the cursor location coordinates, and see when the cursor (swipe) starts at the edge of the screen and moves in. When that triggers (with whatever trigger you want, distance covered most likely) you can fire up your Appbar.
There was a similar question asked on MSDN:
https://social.msdn.microsoft.com/Forums/vstudio/en-US/d85dcde7-839a-44d3-9f2a-8b47b947576c/swipe-gesture-and-page-change?forum=wpf
We have 4 3rd party applications that run on the same machine.
There are a few buttons that we need to manually click every single time on all 4 windows.
The windows are all the same size and never change positions.
How could we simulate a Mouse Click / Mouse Down on these windows? We can't use SetCursorPos/mouse_event since we want to "Simulate" a click and mouse drag in real time. A user's mouse cursor can't be moved, it has to emulate a click.
I can use Spy++ to get the necessary window handle/class, but I would like to know what needs to be sent to the window to make it work.
I have a fullscreen application running on Windows CE 6.0 which will only be manipulated using the finger or a stylus.
So I don't need the mouse cursor, which I'm hiding using Cursor.Hide().
However, when I use the stylus to manipulate something on the screen, the mouse cursor is printed while the stylus touch the screen.
Is there a way to make the cursor not show when touching the screen?
BTW: the application will be the only thing running, so system-wide solution are possible, but I'd rather keep it inside the application.
For a system-wide solution, in case you can create the OS, you can remove the mouse cursor component from the catalog (SYSGEN_CURSOR).
For a local solution here is a suggestion (never tried it):
You can replace the icon with a blank icon so you won't see any cursor while inside your form. Once you leave the borders of your form you can restore the usual icon.
Read How to use custom cursors. I checked that the Cursor class is available with the CF. There are two other functions needed to be P/Invoked that are available under CE:
GetIconInfo
CreateIconIndirect
We have implemented some custom tooltip-drawing code that fires on Tick events of a timer. Whenever this event fires, we check to make sure our control is visible (this.Visible) and is the foreground window (GetForegroundWindow()).
The problem we are having involves "always on top" windows like Task Manager or Process Explorer (when the "always on top" option is enabled). Because these windows are always on top, sometimes our application is occluded/covered by such windows, but our tooltip still pops up and gets drawn on top of the top window.
I have tried to use the Form.TopMost property, but this is not acceptable because then, tooltips never appear if there is an "always on top" window anywhere. In this case, our application is even active, so we should be showing the tooltips.
How do I detect/determine whether there is an "always on top" window covering the area on my form where the mouse is hovering? I want to prevent the tooltip from showing "through" the window.
It sounds like you're polling the mouse position with a timer, and then displaying a tooltip. That's the wrong way to go. What you should do is detect mouse-move messages. If you get mouse-move events telling you that the mouse is in a certain region, then set a timer, and if the mouse hasn't left that region by the time the timer fires, display the tooltip. (Incidentally, that's how native Windows tooltips work. See TrackMouseEvent.)
That solves your problem with always-on-top windows automatically because if part of your window is obscured by an always-on-top window, your form simply won't receive mouse-move events for that region, so you don't need to check whether the mouse is really there.
If you're set on using your current technique, then you can use the WindowFromPoint API function to determine what window is visible at any given point on the screen. Use that to determine whether your window is on top at the place you plan to display the tooltip. (The .Net Framework API map says the .Net equivalent to that API function is Form.GetChildAtPoint, but that only gives children of a .Net form, whereas you need to consider all top-level windows, including non-.Net windows.)