Does anyone know how I can determine if an application is able to accept Tablet PC input? i.e. some kind of hittest or windows message that I can send it?
thanks,
H
The Tablet PC Input Panel (which as of Vista is available even on non-tablets other than the basic editions) will send input using the Text Services Framework (TSF) to an application that supports it. Otherwise it will send normal input messages to the application which basically means a bunch of simulated keyboard events.
I suspect you are trying to determine whether or not an application supports TSF which provides a much more integrated experience such as bidirectional correction interface, information about the current selection, context hints, etc.
I don't know if this is reliable but if the control in question is a rich edit, you could try the EM_GETEDITSTYLE message which has a SES_USECTF flag in the return value that indicates whether or not TSF is turned on for that control. But for standard edit controls I'm not so sure. This article on MSDN goes into much more detail about using the text services framework and is probably more than you care to implement.
Related
I am considering writing a Kinect v2.0 Gesture -> Keyboard/Mouse event translator so I can control video games. Since I will be using Microsoft's SDK, cross-platform is out-of-the-question; it seems natural to distribute this through the Windows store. However, I know Windows store apps have significant restrictions. Can a Windows store app:
Run in the background (possibly with an elevated priority to ensure that the game doesn't miss input)?
Create user input events like "key-down" and "mouse move" that will be read by other applications?
Looking at Microsoft's capability page didn't seem to give me a definite yes or no.
You'll need to write this as a desktop app. Windows Store apps run in a sandboxed context with limited access to the system. They cannot interact with other processes as you'd need, and they cannot inject input events.
Before Windows 8, the method of adding a mailto: protocol handler was straightforward (as outlined here Register Windows program with the mailto protocol programmatically)
As of Windows 8, the old method no longer works. It would seem that Win8 enforces the following key: HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Associations\URLAssociations\MAILTO\UserChoice.
It also appears the ProgID of the selected app is hashed and can't be forged, at least not that I can tell.
Does anyone have a working method for this, or can point me at a utility class/code that'll outline how to accomplish this programmatically?
For code, any language will do.
Edit
I've been asked from other discussions to specify a use-case, so I think it'd be helpful in the context of this question. Please consider this screenshot https://github.com/shellscape/Gmail-Notifier-Plus/raw/master/Promotional/prefs-account.png and the checkbox allowing the user to specify mailto handling. In this use-case, no one is forcing the user, the user is in control and makes the decision. While windows 8 store apps (metro/modern) have an available app manifest entry that automates the missing process described above, nothing seems to readily exist for desktop apps.
You can set your application to be activated by a custom protocol (like mailto:). When the user installs your app, if there is no other app supporting that protocol, they are not prompted and you are automatically assigned to that protocol.
If, however, the user already has an app that handles that protocol, then they will be prompted with a list of apps who support that protocol with the option to select the default. You cannot force the user to make a specific selection.
Also, if the user clicks on a protocol (like myprotocol:) and they have no app installed that handles that protocol then they will be sent to the store (app) which automatically searches for all apps that support that protocol. The user then installs whatever they want. You cannot force the user to make a specific selection (if any at all).
I wrote an article on protocol activation. It might be interesting to you: http://blog.jerrynixon.com/2012/10/walkthrough-using-windows-8-custom.html
So, I made Desktop Firefox my default mailto handler today in Windows 8 by adding the string value "mailto" to the HKCU\Software\Clients\StartMenuInternet\FIREFOX.EXE\Capabilities\URLAssociations and setting the value of "mailto" equal to the ProgID or "FirefoxURL". I then deleted the keys at HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Associations\URLAssociations\MAILTO\UserChoice to allow me to choose the default client again and this time Firefox was available for me to choose.
The essence of this question seems to be that one cannot take over the default client for any protocol anymore (post Windows 8). The user must choose. However, if you wanted to break the OS convention you could hook the call to create the choose default dialog, which would take research, effort, and be only a temporary kludge and would require "breaking" the OS, or you could send a double click to the dialog to choose for the user, assuming your program has elevated rights so that it can send clicks to Admin windows. That would probably be the easiest way, the user would never know what happened, just a quick flash. Really though, after registering itself as a protocol handler, I don't think any program should go beyond deleting the default protocol handler registry entry, thereby forcing the user to re-choose.
This is how to set mailto protocol manually and simply in Windows 8, 8.1, 2012, 2012R2
Add a new registry branch HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\mailto\UserChoice
Then click any mailto: link in your web browser, say IE
and finally there in a program list for you to choose which was not available before.
Also MAILTO appears in Control Panel\All Control Panel Items\Default Programs now. There is no other option to add/remove a protocol from there.
You can't have your app directly take over file associations anymore in Windows 8. There are guidelines for how to handle this for both Windows Store and desktop applications here: http://msdn.microsoft.com/en-us/library/windows/apps/hh700321.aspx
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
I want to simulate hardware key Back from PC. It's for automation test. I use windows phone test framework by expensify, but it do not support real device.
This can't be done on the real device unless you use robots (I am talking with LessPainful and this may happen one day!)
If this is required for your real device automation tests now, then the only things I can suggest are:
that you hook a new custom command into the automation stack and then respond to that command by calling Back on the RootFrame's navigation stack.
this might not be a perfect simulation of what would happen for a real back button press (e.g. if a modal dialog is up) - in which case you'll need to engineer code into your app to simulate the flow of the back press.
if you ask around on XDA developers then someone might have a solution for you (there are ways to hack the OS on your test phont...)
Is there any way switch on/off flight mode programmatically in Windows Phone 7.5. What I want to do is create background task which will be check time and switch on/off flight mode.
Thanks in advance.
No, this functionality is not available.
It was a design principle behind the platform that applications should not be able to do things without the user knowing it.
If such functionality was available then it would be possible for an app (either deliberately or accidentally-though a bug) to get the devices state in a setting other than what they user may expect. In such a scenario users will typically blaim the phone/platform for what has happened, not a misbehaving application.
Though you cannot programatically do it (as others have mentioned), you can send the user directly to the proper page in the settings panel and allow them to do it. Here's an example of using the ConnectionsSettingsTask:
http://msdn.microsoft.com/en-us/library/hh394011(v=VS.92).aspx
You would want to set the ConnectionSettingsType property:
http://msdn.microsoft.com/en-us/library/microsoft.phone.tasks.connectionsettingstask.connectionsettingstype(v=VS.92).aspx
To 'AirplaneMode'.