I'm using the web speech API but once a bit of time passes by (a minute or 2) without any vocal input, it stops listening entirely. I know this because I have it log its parsed text to the console, however, it stops doing this when I do not talk for a minute or two.
Is there any way to fix this?
You can listen to the end event and then restart the recognition on the SpeechRecognition object.
You should use a boolean flag for deciding (in the onend event handler), when to restart the recognition (and when not to restart).
You could use the other recognition-related events for this.
E.g. Chrome triggers the following event handlers when recognition is started:
1. onstart
2. onaudiostart
(only if sound / speech is detected)
3. onsoundstart
4. onspeechstart
If no sound speech is detected, only the first 2 will be triggered, and then, after some timeout, the corresponding end events (in reverse order).
A simple solution for this could probably be to listen for the end event and restart the recognition
recognition.addEventListener('end', recognition.start);
recognition.addEventListener('end', () => recognition.start()) works but Chrome browser seems to obstrruct the continuity by generating a pop-up to Allow or Block the microphone every 5-7 seconds.
Related
I am quite new to windows 8 phone and I don't know all the life cycle methods and when what is called.
My problem is the following: I have a page that loads some data from the disk and when the user exits the program ( or suspends ) the data should be saved. As far as I can tell Page doesn't have an OnSuspending method only someOnNavigatingFrom, but those are not called when you just exit the program. So I read that I should use the OnSuspending in my App.xaml.cs, but this class doesn't have this data and also shouldn't have it, maybe only for OnSuspending. But I don't know how to get the data from my page in the OnSuspending method.
The OnSuspending event is quite fragile and you cannot expect it to run and save the state for a long time. But it depends on how long it would take for you to save. It doesn't even get triggered when you hit the home key while closing the app. If you really want an easy way. Just register a background task. While your app is in the background, the state can be saved and when you open the app again things are in place.
There are certain constraints With Background task as well, you cant do heavy lifting etc...here's a link you could use.
https://msdn.microsoft.com/en-us/library/windows/apps/xaml/hh977056.aspx
Implement an observer pattern (i.e. pub/sub) for your view-models to subscribe to in the event that your app is being suspended.
Your app handles the suspended event. As a result, publish a message for your view-models to respond to within your app's method handler for the suspended event.
You can use an EventAggregator or MessageBus (that I wrote).
I have a Chrome kiosk app that basically just uses webview to allow someone to browse through a catalog.
I found the chrome.idle API, and believe I understand how to set idle time and query if the device is idle, but can I have it restart the application when the state changes to idle or at least navigate back to a set URL?
The end goal is to have the catalog reset itself for the next user after being left idle for a set period of time.
https://developer.chrome.com/apps/idle
Well, the documentation is pretty clear..
First, you need to declare in the manifest that you want to use this API, as it needs a permission.
"permissions" : ["idle"],
You could go with a poll-based approach as you suggested, but why? There's an event provided. So, we go on to use that.
You need to inform Chrome how long an interval without user input you consider an idle state.
chrome.idle.setDetectionInterval(120); // 120 seconds
Lastly, you need to react to a change to an idle state.
chrome.idle.onStateChanged.addListener(function(newState) {
if(newState == "idle") {
// Reset the state as you wish
}
});
I am working on an LOB (side-loading) app and I need to log events, crashes to ETW (Event Viewer logs). I see that most suggest writing own file IO wrapper.
With Windows 8.1, we have new logging capabilities in "Windows.Foundation.Diagnostics" which has classes for "LoggingChannel" and "LoggingSession". But the code sample for them still write to the isolated local storage as files:
http://code.msdn.microsoft.com/windowsapps/LoggingSession-Sample-ccd52336
Also, earlier than 8.1, we have "EventSource" and "EventListener" and as per a sample project (http://code.msdn.microsoft.com/windowsapps/Logging-Sample-for-Windows-0b9dffd7/sourcecode?fileId=67472&pathId=1214683397), it also writes to the sample isolated storage as files.
So, my questions are:
Can we utilize new "Windows.Foundation.Diagnostics" classes to write to ETW?
Are ("LoggingChannel" and "LoggingSession") equivalent to ("EventSource" and "EventListener") ultimately?
Will I still have to write C++ component for writing to ETW?
Forum of Microsoft just gave this answer:
It is not designed with such thing in mind.
I also tried using PInvoke for consuming EventRegister, EventWrite C++ functions. The code runs but I have no idea where find the log. The EventRegister only takes GUID as input and I don't know if it can be mapped to EventViewer application.
Short answer to the questions:
Windows.Foundation.Diagnostics.LoggingChannel writes events to ETW. However, it does not give you complete control over the event in the way that EventRegister/EventWrite do.
LoggingChannel is somewhat equivalent to .NET's EventSource. However, LoggingChannel always writes events to ETW, while EventSource can write to ETW but also has capabilities to bypass ETW. LoggingSession is similar in concept to EventListener, except that LoggingSession always receives events from ETW, while EventListener only works with EventSource (bypassing ETW). Note that you can use both LoggingChannel and EventSource in Windows Store apps.
You will have to write C++ code to use ETW if you need more capabilities than LoggingChannel or EventSource provides.
A few other comments based on things you mentioned:
Event Viewer shows data from the Event Log. The Event Log is not the same as ETW. Event Viewer records data from various sources, and ETW is one of the sources that Event Viewer supports. However, Event Viewer does not record all ETW events -- there are billions of ETW events every hour, and it would fill your hard disk if all of them were recorded. To send an ETW event to Event Viewer, you first have to make your event follow certain rules, and then you have to update the Event Viewer settings to watch for your specific event.
Event Log is designed to record events that are of interest to system administrators and system analysis tools. Because of this design, Microsoft requires administrator privileges to change the Event Log configuration. In order to have your events show up in Event Log, you need to have administrator privileges to change Event Log settings to make Event Log listen to your app's ETW events.
LoggingChannel does not support the necessary settings to make your ETW event look the way Event Log expects, so LoggingChannel cannot be used to write to the Event Log.
If you use EventRegister and EventWrite, you can write events in the format that Event Log expects, but you would still need to have administrator privileges to change Event Log settings to accept your events.
Note that EventRegister and EventWrite (and LoggingChannel) are for sending data to ETW. You can send anything you want to ETW, but by default ETW will just ignore it and throw it all away. ETW is the system for routing events from the provider to anybody who is interested in the event. If nobody is interested in the event, it gets thrown away by default.
LoggingChannel writes events out to ETW, but ETW will just drop them unless there is a session to record them. From within your app, you can record the events using LoggingSession. From outside your app, you can record the events using a tool such as xperf or tracelog.
You can use Windows.Foundation.Diagnostics.LoggingChannel from Windows 8.1 to write ETW events with some limitations. In particular: all events from all apps will always use the same provider GUID (4bd2826e-54a1-4ba9-bf63-92b73ea1ac4a), there is no way to access the keyword, channel, task, or opcode features of ETW, and you can only write very simple events. The Windows 8.1 LoggingChannel API is mainly focused on providing a simple string-based logging facility.
Windows 10 adds a bunch of new features, removing many of the limitations. You can use a different provider GUID (so it is easier to record just the events from your app), you can set keywords, tasks, and opcodes, and you can write strongly-typed events (i.e. events with strongly-typed field values instead of just a flat string). The Windows 10 LoggingChannel API allows you to use LoggingChannel for fairly advanced ETW scenarios, though it still works for simple logging.
In order to get the keyboard state we can listen to "keydown" event but is it possible to interrogate the keyboard without an event? Something like window.keyState.shiftkey?
In 2018 I'm investigating the same thing: (re-)initialisation on acquisition of focus.
Initialisation (determination of system state) is required when the application starts. It is required every time the application recovers focus after losing it to another application, because state like NumLock can change while the application does not have focus.
As the question notes, this information can be obtains from event objects.
There doesn't appear to be any way to request this information.
This requires a change to browsers. In my opinion a low impact solution
for this and parallel situations is a general mechanism for requesting a "null event" of a specified type, eg
var ke = window.requestEvent("keyboard");
var me = window.requestEvent("mouse");
var te = window.requestEvent("haptic");
Since a keyboard/mouse/touch event is not actually occurring, the field that would otherwise quantify the event (key code, mouse position etc) should be null.
This API should not be a breaking change for event handlers, since it doesn't actually trigger an event, it's a function that returns an event object. It's completely new so there is no legacy code, and it can be extended without change simply by defining more event class strings. No new data structures are defined.
If I knew how to submit a change request to the pertinent browser standards committee, this seems to me like a very tight, robust, compatible solution to several problems. I'm recording this here as a sort of message in a bottle, in the hope that one day it will be seen by someone who can act on it.
We want to create a Windows desktop version of our weather widget
There are 2 special things about the widget.
It consumes a lot of processor time
while active - it displays an
animated picture (Flash without GPU acceleration, unfortunately).
It updates the weather from our
server (frequent server requests from all widget users).
When the user does not look at the widget there is no need for animation and weather loading.
So I have an idea of putting my widget to sleep when it is not visible and hense not used.
Is it possible to detect whether the widget is used or not.
Speaking precisely I need to know whether the widget is covered by other windows?
I mostly interested in Vista/7 gadgets engine, however I also would like to know if this problem is solved in these widget engines
Yahoo widgets
Google desktop
Hope to find some desktop widget guru here.
Pasha
If you InvalidateRect and don't get a subsequent WM_PAINT message, than your window is hidden. You can call UpdateWindow after InvalidateRect to force the WM_PAINT message to happen (or not happen) right away.
So you could do something like this
request server data (and cancel request timer if any)
when data arrives InvalidateRect
when WM_PAINT message arrives, draw the data and set a timer for next request
when timer arrives, goto 1
When you stop getting WM_PAINT messages, you stop re-setting your timer, and you therefor stop requesting updates from the server. When the WM_PAINT message happens (because you are no longer covered). You start requesting data again.