One nice ascpect about MIDI is that one can route it explicitly to some app - unlike regular input devices like your run of the mill mouse or keyboard.
Is there a similar way to use a Wacom pen tablet exclusively with one app that doesn't even have a visible window resource (Windows 10)? I'd like to repurpose it as a jog dial for video editing and need to intercept the device data in order to simulate specific key presses or mouse movements.
Here is what I'm currently working with:
https://github.com/Wacom-Developer/wacom-device-kit-windows/tree/master/Wintab%20ScribbleDemo
https://developer-docs.wacom.com/intuos-cintiq-business-tablets/docs/wintab-reference#logcontext
The scribble demo works fine out of the box. Setting g_penMovesSystemCursor = false makes the system cursor ignore the tablet, but only as long as the demo's window is in focus. I want the system cursor to always ignore the tablet input and the demo to always receive the wacom events.
Well, I guess this answers it:
How can my application have exclusive access to all tablet pen events?
You must force your application to be the front-most (foreground) app.
https://developer-docs.wacom.com/intuos-cintiq-business-tablets/docs/wintab-faqs#how-can-my-application-have-exclusive-access-to-all-tablet-pen-events
Bummer. Such a simple and useful thing for an input device, and it's not supported.
Related
OK, I get it: focus stealing is evil. Or at least it is 99.9% of the time. But I really need to steal the focus reliably on Windows 8, and so far I'm thwarted by the hordes of people insisting focus stealing is always evil.
Scenario: we run a custom application on an ordinary PC running Windows 8.1 (soon to be Windows 10). The screen, keyboard and mouse sit roughly 5m off the ground up some stairs that the forklift operator really shouldn't climb. The one input device they have is a numeric keypad on an extender cable down at their level. Everything they need to do they can do from that keypad... so long as some evil program hasn't stolen our application's focus, or some remote user hasn't logged out and left another application with focus.
The application is essentially a maximised desktop application - it fills the screen (but is not strictly a "full screen" or "topmost" application), and therefore allows other applications to appear in front of it when required. But when the mouse goes idle, we want this application to resume its "normal" position in front of all other applications so that it gets focus and the numeric keypad input will work reliably.
On Windows 7, using SetForegroundWindow() (enabled by AllowSetForegroundWindow() works fine - the application can be brought back to the front and resume focus. On Windows 8, SetForegroundWindow() only results in the taskbar icon flashing, but the application does not regain focus, forcing our user to climb the stairs... where the full keyboard and mouse is too tempting for them not to press buttons they shouldn't, and chaos typically ensues.
So please sir: can our (MFC, desktop) application steal back the focus once the mouse has gone idle for 1 minute, because it is more or less the only application that should normally be running anyway. If that is permitted, how do we steal it reliably?
Configure hotkeys on numeric keypad (RegisterHotKey).
Pressing a registered hotkey gives you the foreground activation love by Raymond Chen
After you call the RegisterHotKey function to register a hotkey, the
window manager will send you a WM_HOTKEY message when the user presses
that hotkey, and along with it, you will get the foreground love. If
you call SetForegroundWindow from inside your hotkey handler, the
foreground window will change according to your instructions.
Possible solution (with major limitations): do nothing extra; wait.
One of our service technicians observed that on the third or fourth attempt to regain focus using AllowSetForegroundWindow() and SetForegroundWindow() as had been working on Windows 7, Windows 8 finally allowed our application to regain focus. It is not clear what the conditions are that make this work, or if it works reliably, but we have now observed our application regaining focus from beneath Chrome, from beneath another (self-developed) MFC application, and from beneath a third party application - all desktop applications. Approximately 3-4 minutes needed to elapse in each case before focus was surrendered back to our (desktop) application.
However, we have not witnessed it regain focus from beneath metro applications, and nor do we expect it (e.g. hit the Windows key and leave the system lingering on the Start screen).
In our (restricted) situation, we are willing to take the gamble that our users will not launch a metro application that obscures our desktop application, at least not without restoring our application, since their business relies on it. Our main concern is that one of our busy service technicians will log in remotely, get distracted, and carelessly leave one of our desktop utilities with the focus. Waiting 3-4 minutes appears to be a solution to this specific scenario.
I would try it in this way:
Setup a timer in you application. That checks GetForegroundWindow on a regular basis.
If GetForgroundWindow does not belong to your process (GetWindowThreadProcessId)
If a different process onws the foreground window use AttachThreadInput and attach your input queue to the input queue of the other process.
Now use SetForegoundWindow and detach the thread input again.
Now you can use SetFocus as needed to control the input focus of your program.
I'm currently trying to develop an application to use two mice to perform completely different actions in Windows. However, after having spent couple days on it, I'm starting to wonder if what I want to do is even possible using Windows APIs. As I'm far from being an expert in Windows APIs, I would like to get your opinions to know whether I'm going in the right direction or whether I should try to do it completely differently (maybe developing a driver ?).
Here's what I want to do : Imagine two mice are plugged in my computer. I would like to use the first one as a regular mouse, while the second one would be used to perform completely different actions. For instance, by clicking the second left mouse button, it would open a new tab in Firefox (sending a CTRL+T command to FireFox app) and when clicking the right button, it would send a CTRL+C. Then, by moving the second mouse upwards, it would zoom in, and when moving it downwards, the firefox page would zoom out (so the mouse cursor on screen would remain fix while doing that !). The idea is to recognize as well which application is currently used (which one has mouse/keyboard focus) and perform different actions depending on it. So for instance, the second mouse left click would generate a CTRL+T in FireFox, a CTRL+B in WORD and a CTRL+S in Notepad (in fact, the idea is to parameterize those actions at will). All of that while the first mouse must continue to act just as a regular mouse.
So, it's important to understand that my application will run in the background and will never, per se, interact directly with the user (no GUI as it doesn't require the user to input anything). Its purpose is just to modify the mouse inputs coming from the second mouse and send other inputs(messages) to the application currently being used.
So far, I'm using raw input. I'm able to differentiate which mouse is being used and I'm able to send messages (application specific) to other applications when an action is performed on the second mouse. I'm even able to lock the cursor on screen when the second mouse is moved (so as only the corresponding message is sent to the application of interest !). However, I'm unable to block the button messages sent by the second mouse to the app with the mouse focus. Hence, when clicking on the second mouse right button in Notepad for instance, my specific command ("aaa" for the moment as I'm just trying with letters for sake of simplicity) is sent (and displayed in the notepad window) BUT the contextual Notepad menu opens as well… (hence it's received as well a WM_RBUTTONDOWN message).
My question is then : How can I block the mouse button messages ((WM_RBUTTONDOWN, and so on…) to be received by other applications when the second mouse is used? Is it even possible ? The problem is that (in my understanding) those messages have higher priority over the WM_input messages… So when I read the WM_input message in my application and detects that the button was pressed from the second mouse, it's already too late and the WM_xBUTTONDOWN was already sent !)
I know that using the mouse hooks, I could block those but then, there is no way to differentiate the origin of the message (and of course, detecting which mouse is used is the main point of my application).
I've tried as well using DirectInput8 but it doesn't support anymore the usage of several mice (Windows specifically says to use raw input to this effect).
So, I guess that by know you've gotten that I'm quite lost and have no idea whether what I want to do it even achievable. Any help would be more than welcome.
Looking forward to reading your replies.
I was about to suggest hooks, but then I read that you looked into that already. I guess, the last resort for your problem would be to write your own driver.
After Windows installed the second mouse in it's usual way, you can go to the Device Manager and change the driver of the mouse you want to "repurpose" to your own driver.
Although, developing a driver is probably nothing one will do as a side task in a project.
Background
I'm implementing a simple WIN32 application consist of a window.
The user may show/hide the window using a special hotkey. I register the hotkey using RegisterHotKey and respond to WM_HOTKEY
Problem
if user plays a game and accidentally (or not accidentally) press the hotkey combination, then my window pops up and as a result the game is minimized.
Question
Is there a (native) way to know that the user is in gaming mode, or any other special mode, that I could disable the hotkey response
Note
I would also like if windows would make this a feature while I play games. For example don't respond to WinKey+D while I'm in gaming mode.
You can use the SHQueryUserNotificationState function to determine whether the user is playing a full screen D3D game. It will report QUNS_RUNNING_D3D_FULL_SCREEN.
My ultimate wish is to allow users using a touchscreen desktop (an All-in-one computer without mouse or keyboard) to navigate on a website that uses tooltips. Using a mouse, hovering over a tooltip opens it, the tooltip contains links that can be clicked. Using a touchscreen, there is no hover, only 'touches'/clicks. In both cases the page will be displayed on the same OS using the same browser, once the user has a mouse, the other time the user has a touchscreen.
So I need to distinguish between the two: a desktop computer with a mouse and a touchscreen desktop computer without a mouse. Modernizr touch tests (http://modernizr.github.com/Modernizr/touch.html) fail completely on a touchscreen desktop (http://shop.lenovo.com/us/landing_pages/thinkcentre/2010/m90z). Sniffing the UA or browser does not work either.
(After a fair amount of searching, all the detection tries to distinguish different versions of mobile phones or tablets, browsers, UAs... Not desktop touchscreens that are running on the same OS using the same browser.)
Any ideas?
Add event listeners touchstart and mousemove to your page, then wait the user starts to interact with your page. If the first event is mousemove, then user operates with mouse, so it is probably a desktop, otherwise this is a touch-screen.
$(document).on('touchstart.desktopDetect mousemove.desktopDetect', function(ev) {
window.IS_TOUCHSCREEN_DEVICE = (ev.type == 'touchstart');
$(document).off('.desktopDetect');
});
Check working example here:
https://jsfiddle.net/evpozdniakov/uvb51cnm/embedded/result/
I am developing an application for Windows 7 devices and I'm using an embedded web browser (webkit). Normally touching an edit control on a tablet device causes a little keyboard icon to appear. However, since my edit control is in the browser, it's not a real window with an hwnd and Window's doesn't bring up the icon you can click on to bring up the on screen keyboard.
Is there an API I can use to cause the little keyboard icon to appear as it normally would when focus goes to an edit control?
I tried searching MSDN, no success.
I looked at the Windows keyboard API. No dice.
I tried running OSK.exe. This could bring up multiple instances of the keyboard and it's just sloppy. I want to get the same effect a user would get when tapping a windows edit control so the UI is consistent.
There must be an API that can bring up that on screen keyboard.
Thanks.
David
Not sure if you have this answered already. I have been looking at doing a similar thing although it is a part of a larger application and the keyboard is rarely used (but nevertheless had to be supported). I assigned a shortcut key (right click Win 7 on screen keyboard application and choose Properties. In the shortcut tab, assign any shortcut you'd like). When I touch a SurfaceTextEdit control, I emulate the shortcut key from my C++ code using SendInput(). I know this is a hack, but it worked well for me because I rarely used the onscreen keyboard in my application.