I work with SpeechRecognitionEngine from the namespace System.Speech in inproc-mode for doing some automation work. The speech recognition is started via RecognizeAsync.
It works fine, however, when the computer gets locked, speech recognition stops. As soon as the computer gets unlocked, the recognition is active again.
While this is probably a meaningful behavior for most applications, for mine, it is an issue. I have searched the web, but not found a solution to disable this behaviour.
How can I parameterize the SpeechRecognition not to stop when the computer is locked?
(Please note: The app is a conventional Windows WPF application, not a Windows Store App)
Some ideas which might be too crazy to work to hopefully trigger some ideas that might work:
Using ControlChannelTrigger to keep pinging your app to wake up and try recognizing speech at intervals? This listener allows your app to process network data in the background.
Try out Google Chrome's hotword (OK, Google) extension and see if it works behind the lock screen. If they can do it, then it's possible.
Do you have to lock the screen, isn't it possible to not have it locked?
Some references:
http://msdn.microsoft.com/en-us/library/windows/apps/dn263238.aspx
http://msdn.microsoft.com/en-us/library/windows/apps/hh977056.aspx
Similar questions:
http://gotspeech.net/forums/thread/11826.aspx
http://social.microsoft.com/Forums/en-US/2ab82528-0d1c-492e-9c15-38730d88b3e9/speechrecognitionengine-pauses-on-lockscreen?forum=Offtopic
Do you have "Enable voice activation" option enabled in Windows?
It looks like the behavior you describe is expected when "Enable voice activation" option is disabled in Control Panel | Speech recognition. Though, it can be unrelated to locked Windows.
See "Setting speech options":
Enable voice activation
Sets Speech Recognition to start in sleep mode and allows Speech Recognition to enter sleep mode when you
say "stop listening."
On the other hand, I don't think that using Speech Recognition with locked device is valid operation (security reasons). Unless you are going to spell your password instead of typing it. :)
See this article on how to launch an application on the secure desktop (a.k.a. lock screen).
Related
I Develop a medical device that runs Windows 10 Ent. 1809. since this is a medical device, must Windows Explorer and other Windows settings need to be restricted from the user that operates this device.
So I Had to turn change most of the Registry values in
Computer\HKEY_USERS\Medical\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer
The problem that I am facing is this annoying "This operation has been canceled due to restrictions in effect on this computer" message, which I DO NOT want my user to see.
How do I prevent this message from showing?
I basically searched all over the internet for a solution. But I couldn't find any information on the matter, except on chat from Microsoft forum which, surprise.. surprise..., was not helpful.
My Windows Phone XNA game calls Guide.BeginShowKeyboardInput to get the user's name. While the Guide's input screen is shown, if the user presses the Home or Search (hardware) buttons, the game is deactivated as usual - but if the user then presses the Back (hardware) button, the game should resume but it doesn't. Instead it shows the "Resuming..." message until Windows Phone gives up trying to resume the game and kills the process.
Please note:
My app is failing Microsoft certification because of this problem - I really need to fix it!
This only happens in my game when the Guide input screen is shown - when it's not shown, the game
resumes properly after being deactivated.
This problem only occurs when the game is run on WP7.x (verified problem on WP7.5 and
WP7.8) - although the game seems to resume properly on WP8 devices.
I've created a blank XNA game project, called Guide.BeginShowKeyboardInput and tested it using WP7.x devices, and this problem-behavior doesn't occur.
I've tested the game without enabling Music & my Trial License manager (they use timers) and it still does this.
Exact same behavior occurs in the emulator (resume-failure on WP7.x emulators, works fine on WP8
emulator)
I used threads to asynchronously download content during the loading screen - but they already completed and exited.
I don't believe other threads are running, although this seems like
it could be a thread-blocking issue.
Any other ideas on what could be blocking the game from resuming when the Guide.IsVisible or how to debug/resolve this problem?
The solution to this issue was simply to NOT use SuppressDraw when dealing with any operation that passes control outside of the app, e.g. Launchers, Choosers and the Guide.
Have you tried calling "Guide.EndShowKeyboardInput" in either the Deactivating or closing events?
So that the guide is closed before the app suspends, you do get 10 seconds to suspend so this might be worth looking into.
If you want the guide to re-show on resume, then in your state saving code just have a flag and open the guide if it's set.
I'm using the ShareLinkTask in an app I'm developing, however, on the emulator it doesn't appear to do anything, not even pretend to go through the motions. Is this the sign of a bug with my code, or is this just how the emulator behaves?
That's the way the emulator works with this task.
From msdn
Allows an application to launch a dialog that enables the user to share a link on the social networks of their choice.
The emulator does not have any social networks so nothing to share.
I am developing a security related windows phone application. I need to disable/block screen capture for my application.
In Android, we used to set a flag FLAG_SECURE to the window of which we want to block the screen capture. Is there anything similar in wp7 also??
Thanks
You can't do screen captures on Windows Phone unless you use homebrew apps, so I wouldn't worry too much about it.
And even if there were screen capture apps on the marketplace, you would have no way to be safe. Even if you found a way to prevent screen captures, how would you prevent users from taking a picture of the phone with a camera, or sideloading the app on the emulator then making screen captures of the emulator?
There's currently no API available to developers that allows you to perform screen captures with a locked device.
The alternatives are as follows:
Unlock your device and sideload one of the homebrew based screen
capture apps.
Take a picture of the screen itself (Crude but it
would do the job).
Microsoft have stated that they do not intend to change this in the near future (CNET Article)
Is it possible to track the accelerometer value while under the lock screen?
I managed to write a simple application which counts from 1 up to 100 using a timer which fires an event on which I increment a counter.
But when I use register a handler for the ReadingChanged event of the accelerometer it will not be fired anymore once the screen has been locked. Even if I unlock the screen again I will have to readd my handler.
the msdn documentation tells on the one page:
http://msdn.microsoft.com/en-us/library/windowsphone/develop/ff941090(v=vs.105).aspx
"Valid reasons to disable idle detection in Windows Phone OS 7.1 applications include ones where core functionality continues while the phone is locked (for instance, an exercise tracking app)"
but the sensor api also tells:
http://msdn.microsoft.com/en-us/library/windowsphone/develop/hh202968(v=vs.105).aspx
"The Sensor APIs cannot be used while the application is running under the lock screen. For more information, see Idle Detection for Windows Phone. The Sensor APIs also cannot be used in background agents. For more information, see Background Agents Overview for Windows Phone"
I hope they will change the api soon, because of that it is not possible to write any good sleep tracking / sport tracking applications ... :(
I was helping a guy with this a couple of days ago. He had an app that tracks GPS and accelerometer data under lock screen.
Turned out the app accelerometer data stopped tracking when under manual or auto lock screen.
There may be an issue here to be looked into.
Under lock screen it is a good idea to minimise power usage... disable all uncessary code, like ui updates. My understanding of one the motivations for idle detection and running under lockscreen being opened up during CTP was in response to a lot of feedback from developers of map/tracking apps that basically need this for their app to be of any use.
I'm not sure of the usage case where you'd want to use the accelerometer under the lock screen.
Apps typically run under the lock screen when you need them to do something when you're not interacting with the device. e.g. playing music or downloading a large file.
If you wanted accelerometer data I'd assume that the device is being held and, therefore, presumably, looked at. Given this, why would you therefore want to run under the lock screen?
That being said, if you had a good reason to do so, you should still be aware that:
when your application runs under a locked screen, it ... must minimize
power usage
(from the Marketplace Certification Requirements.)
In my understanding, reading values from sensors is not minimizing power usage.