I am currently writing an application that receives touch input through the windows WM_INPUT messages and the HID API. Every touch point received has a handle to the device associated from which it came. This is the same device that the family of WM_POINTER messages would report for the same touch point. My application needs to know which monitor corresponds to a particular touch device. Is there a programmatic way to determine this? If I was using the WM_POINTER API I could use MonitorFromPoint or something similar.
In the control panel under "hardware and sound" there is a category "Tablet PC Settings". If you click this category, a dialog box launches which has a button "Setup". This button launches a calibration tool which allows you to pair a USB HID touch device with a monitor.
Does anyone know where these settings might be saved to?
relevant links:
structure received in WM_INPUT messages:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms645562(v=vs.85).aspx
Structure received in WM_POINTER messages:
https://msdn.microsoft.com/en-us/library/windows/desktop/hh454907(v=vs.85).aspx
Thanks.
A generic way to determine where things are stored in the registry, is to watch registry changes. Process Monitor from the Windows Sysinternals Suite by Mark Russinovich, can be used to watch and log changes to the windows registry. So you can start it logging, and then perform your calibration, and then stop and examine the log for the desired registry activity.
Here is a link to a similar question I asked
Associate HID Touch Device with Pnp Monitor.
In short, you can use the details from the HIDApi calls with queries of registry keys to link HID Touch Devices to monitors.
Related
I have a Bluetooth low-energy device paired to my Windows 10 machine, when an application try to use it, Windows automatically connects the paired device. I want to be able to read if the device is connected or just paired to Windows. Searching around Window's Device Manager (accessible from Control Panel), I saw that the device had the property "Is connected" under the details tab, it's value (true/false) was changing accordingly to the actual device status.
I tried to read to access this property using the SetupDiGetDeviceProperty function with the DEVPKEY_DeviceContainer_IsConnected predefined key but for some reason I get ERROR_NOT_FOUND.
Any ideas?
I need to starting my app when our USB device connected.
My first attempt at this is a background application that pays attention to when USB devices are plugged in. When it notices our device connected, it calls ShellExecute( ) and starts our application.
This works nicely except in Windows 8. Supposing we're on the "Start" screen in Windows 8. In that situation, the application starts in the background and the start screen remains in front.
I think this is a "focus" problem since what I'm actually hoping to do is "steal focus" from the Start screen.
http://blogs.msdn.com/b/oldnewthing/archive/2009/02/20/9435239.aspx
Since my background application doesn't have focus (the Start screen has focus; besides, my application doesn't have a UI), it can't give focus away to my foreground application.
Let me say that in general, I hate focus stealing. Starting the app the user wants to use is a great help to our users.
How can I fix this problem? Maybe the answer is to programmatically ask the start screen to start my app but I don't see a way to do that:
http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/9ed23f32-0708-48a8-9ff7-5fce6dbe123f/windows-8-start-screen-api
Maybe I'm approaching this in the wrong way. Suggestions?
You're going about this the wrong way. Although you can write a program to constantly monitor the USB ports to detect when something is connected, there's no need. The OS is already doing that anyway.
Register an Autoplay handler for your device type and class. This is distinct from the old AutoRun feature, which would automatically execute programs found on an inserted file system.
You can begin with an overview of the feature from the November 2001 issue of MSDN Magazine.
Your handler will be a COM DLL. You can register the DLL as a handler, and register the handler with events you want to handle. You can either perform everything in the DLL, or you can put the bulk of the functionality in your application and just use the DLL as a proxy between the OS and your program.
I got a letter in the mail that contained a small USB device. Here is what it loks like: http://imgur.com/a/VEtNK
When I plug it into my computer it seems to hover over the programs in my Dock and then opens one. It then types a link into a text field that is available. I originally had Skype in the dock and it defaulted to that one, strange. I removed Skype from the dock and now it opens to System Preferences.
Here's a video of what happens as I plug it in: https://www.dropbox.com/s/yuw6ggvo77rkvwh/Test1MysteryDevice.mov
Also, it does not appear like a memory stick does on my computer. I can't seem to locate it when it's plugged in. It would be cool if I could find it somehow. It would be even cooler if I could program it to do something I wanted.
Thanks, and if anyone can help out that's awesome or if you could point me to a forum/anywhere that might be able to help out, that'd be great!
Probably it self-identifies as a HID (Human Interface Device), specifically a keyboard. As soon as it is accepted as a keyboard by the OS it can send any sequence of keystrokes, and the OS will assume that it is input from a human user.
Scripting such behavior is easy using Applescript.
However automatically running a program from a USB stick when it is inserted is supposed to be impossible on OS X, as auto-run is a security risk.
Of course at the very least a custom USB device could be made to act like a mouse and keyboard, so even without autorun it's a risk to plug strange devices into your computer.
To get more info on the device you can go to System Profiler and look for the device on the USB bus.
If it is a custom device pretending to be a keyboard then it's probably hardwired to do what it does, and you probably won't be able to reprogram it; you'd need to find a manufacturer that will sell you customized devices.
I have 3 monitors, but I don't need them all turned on all the time. I can just shut them down with power button, but I want to use their standby mode, like Windows does when we let PC idle for a while - it shuts down monitors, HDD, etc.
But of course, I wanna keep using PC and let just that monitor on standby. Others must remain on and that one doesn't wake up even with me using PC.
Is it possible to do that? It would be great to have a shortcut like Winkey+1, 2, 3 etc to shut down and wake up each monitor.
An existing app with this feature is not likely to exist, but is there a Windows API function that can control monitor state, for each monitor in a MultiMonitor system?
The display control panel applet calls SetDisplayConfig to start or stop forced projection on a particular target
You can probably use MS Detours or some other API hooking tool to inspect the usage pattern of the API while using the applet to adjust display settings.
You'll want to try Display Fusion. You should be able to do what you're asking for using Monitor configurations.
I know I'm late on this but use DDC to control your display. You can easily create hotkeys that send a command via DDC to the display to turn-off. This would be equivalent to turning off the display using the button. Works like a charm for me. The only trick is that DDC command specs vary across monitor manufacturers but its not hard to find the right codes to send with the help of google.
Ready made tools also exist for this; search for anything that is related to DDC or EDID and you should find.
Be aware though that this does not remove the display from Windows which means that apps may find their way onto displays that are off and you will be looking for them.
I'm having some problems with multi-touch and LabView.
My objective is to intercept the Windows Touch Messages (generated by multitouch monitors and then interpreted and handled by Windows 7), which are intended for any and all windows owned by a program called LabVIEW.
This will prevent Windows from communicating Touch Messages with LabVIEW while allowing me to use the touch messages to create custom responses in LabVIEW myself. And, it will still allow Windows to use the Touch Messages as normal for any and all other programs which the user may want to interact with.
LabVIEW has not been registered with Windows 7 to interpret Windows Touch Messages specifically. It therefore handles them using default Windows 7 responses.
I have developed a library for LabVIEW which creates the custom multitouch enabled responses but it requires me to provide my own driver for the multitouch monitor being used in order to prevent Windows 7 from listening to the monitor's touch event messages and converting them to its own set of Touch Messages. This is inefficient as I want users to be able to plug and play any commercial multitouch monitor with my code and I don't want to have to write custom drivers for every monitor type.
So, I want to intercept the Touch Messages intended for LabVIEW (and only those Windows Touch Messages) so that they
Never reach LabVIEW
Can then be sent on to my existing program for reinterpretation via TCP messages over the localhost (this seems the best way I've found so far).
If anybody has any ideas I'd be exceedingly grateful!
LabVIEW does not see the Windows Touch Events as you already know. The only events you see are the ones you can use in the Event Structure. However, there are ways to use .Net Callbacks to see other Windows events. You can then create User Events to feed the event back to your Event Structure. Below are a couple of links that might help:
Capturing Windows System Events without Polling (Windows)
Windows Message Queue Library
Use windows touch screen (multi touch) and distinguish get touch event and mouse click
Use the event handler structure in a while loop and only register the events you want LabVIEW to handle.
If you are willing to pay for it, there is a commercial toolkit that supports multi-touch and smartphone-style gestures on a number of touchscreen devices via UDPP or Windows 7 messages:
https://www.ni.com/en-us/shop/software/products/touchscreen-toolkit-for-labview.html