In MIT App Inventor, there is a media component called TextToSpeech. It has a method called Speak(text message), which speaks a given message.
However it has no method to stop speaking. Imagine when the message is long, it can keep speaking for a long time, which is not desirable.
Wonder if there is a good way to ask TextToSpeech to stop speaking?
An efficient way to ask TextToSpeech to stop speaking is to call TextToSpeech's method Speak(text message) again, with an empty text. As a result, TextToSpeech will stop speaking immediately.
Here is an example. Suppose that TextToSpeech1's Speak method has already been called to start speaking a long message. Now click Button1, and in its event handler you can call TextToSpeech1's method Speak(text message) with an empty text, as shown below. TextToSpeech1 will stop speaking right away.
Note on the App Inventor version I'm working with:
Built: September 27 2019 Version: nb180
Use Companion: 2.55 or 2.55u or 2.55 or 2.55uu
Target Android SDK: 28 (Android 9.0 Pie)
Related
Is there a way to know if the app is sent to background or brought to foreground. I don't mean Suspended and Resuming events.
For example, user leaves the app to check something on Facebook app for a min. And then return to back to my app. So suspention doesn't take effect on this scenario. Then how to know user is back to the app on app.cs level?
As stated in the MSDN documentation:
Your app doesn't receive an activation event when app visibility changes, because the app is still running. Windows simply switches to and from the app as necessary. If your app needs to do something when the user switches away and back, it can handle the visibilitychange event (for HTML) or Window.VisibilityChanged event (for XAML).
I currently have a "dumbphone", but I'm trying to make an app that'll time and store the call duration of incoming calls for windows 7.1 ("7.5") phones, for the user scheduling purposes.
However, after extensive searching and googling, with topics like this one:
Windows Phone 7 - How to calculate call duration or termination
it seems that the Windows 7/7.1 SDK does not allow access to recognizing when a call is coming in. I've read about obscure and unobscure, but that this wouldn't be a good idea since it would start the timer anytime the UI hides the program, not just calls.
I've thought that maybe I could just pull the call duration or the start/end time from the call history, but windows 7 SDK doesn't support that either it seems.
So I decided to seek help. Is there a way to make this work? Is there some clever way to recognize when a call is incoming and stopped? Or some clever way to pull call times/durations? Or maybe a way to detect when the user presses that "accept incoming call" button? Or maybe a way to single out when a call is obscuring the UI?
Any help would be greatly appreciated. Thank you
Due to security reasons your application does not have any kind of accsess to call history ect. So you are in a sendbox and you don't know nothing about phone calls.
From the Windows Phone SDK, there is no way to achieve this!
The only thing I can think of is that when a call comes, the current app gets notified that is now Obscured because a new screen is now on top of it (the caller ID screen), and will get notified when it gets back to focus.
But the truth is that this happens even if a SMS message notification pops on the screen and the user taps to read it, or some app gets a notification pushed...
I wonder if it was possible to force a call without using the messagebox confirmation (in debug mode for example...)?
I use currently PhoneCallTask to make a call.
(My application should never go on the market place)
Thank you for your answers,
There is no other way to make a call then using PhoneCallTask(), even if your app is not going on the marketplace.
The current Windows Phone SDK only provides the PhoneCallTask to make calls, and this class shows the confirmation message box, so the answer is no...
I am in the process of porting a Flash Player-based game over to the Desktop (OSX and Windows) via Adobe AIR (3.1). The porting to AIR itself has gone rather smoothly. The one wrinkle I've been dealt is that the game will be distributed over the Steam network. In order to interact with the Steam Client, I've had to write a native extension to expose the Steam SDK APIs to AS3. The native extension support has been implemented for both platforms, and I have the application launching and communicating with Steam as desired.
The area I've run into trouble is dealing with Steam's Overlay, which renders overtop of games when it is activated. Essentially, when a game is launched, the Steam Client suspends the process in order to hook its Overlay library up to either D3D or OpenGL. Initially, the Overlay failed to appear at all as the AIR application descriptor had the default rendermode set to "auto." However, once I switched the rendermode to "gpu" the Overlay would appear as desired.
On the OSX side of things, everything works as expected. I can toggle in and out of the Overlay just fine. On the windows end of the spectrum, I've hit a bit of a problem when I activate the Overlay. Specifically, when the Overlay is enabled (it's rendering overtop of the game) and I either move the mouse or generate keyboard input, both the Overlay and the game both "freeze" (rendering stops) for 2-3 seconds. Additionally, I have noticed that when I open the Task Manager with the game running, the cpu usage is roughly 75-80%. The cpu usage remains the same when I first active the Overlay (which is desired). However, when I move the mouse cursor or press a key on the keyboard, the cpu usage drops to roughly 1%. This problem has occurred on 4 of 5 windows machines (2 XP, 3 Win 7) we've tested on. Naturally, I first contacted Valve about the issue since this only occurs when the Overlay is enabled. I've uploaded both the OSX and Windows builds for their devs to debug; however, my contact suggested I find out more about AIRs rendering/input as well.
Here is a snippet of a post with a Steam Dev detailing how the overlay works:
"The requirements for the overlay on Windows are as follows:
Game must use D3D7, D3D8, D3D9, D3D10, D3D11, or OpenGL
Game must call D3D Present() or OpenGL SwapBuffers() on a fast regular basis (these calls are hooked by the overlay and give it opportunity to do work). For instance 2D games that only call these functions when mouse movement occurs or graphics on screen actually change rather than every frame will not function well.
Game should use standard Win32 input messages, raw Win32 input messages, or DirectInput for input and the overlay will then detect hotkeys and hide/block input events from the game when active.
It sounds like your game may violate #2 and stops calling Present/SwapBuffers sometimes when the overlay is active. This may happen if you call these functions in response to user input which is now blocked due to the overlay being activated. You should guarantee you keep pumping frames and swapping at a regular interval even if input events aren't occurring."
After a little more prodding, the Valve devs profiled my application to determine if there was any specific problem occuring with the Game Overlay. Unfortunately, they were unable to find anything going on in the Overlay itself. This pretty much means that AIR on Windows doesn't like that the Overlay is blocking Win32 input messages. Here is the Valve dev's response:
"I got your depots and did some testing. Nothing unusual happens in the overlay. Profiling your app with xpref while the issue occurs and taking some minidumps to check callstacks it looks like the app just blocks up completely and uses zero CPU during the time it is blocked, when it happens it calls Present() only at roughly 1 second intervals until it recovers (maybe there is a 1 second timeout somewhere in the AIR code). It's hard to get much detail since I don't have any symbols for the AIR runtime libraries.
It does however look like this is somehow related to input state and AIR being unhappy with win32 input messages stopping. If I change our overlay to not block any input at all once activated (which obviously has some pretty big problems for usability, but just for testing purposes.) then the issue does not occur. It's possible that the AIR code has some weird logic where if it's seen some specific WM_WHATVER message it's expecting another right after and blocks on it waiting somehow.
Hopefully you can work out on your side or with Adobe as to why the application behaves badly in these situations and starts blocking and not presenting at regular intervals."
I've posted on the Adobe forums, but haven't had any such luck over there. Mainly, I'm hoping that someone has either dealt with this before or has an idea about how I could possibly get around the issue. Any suggestions, comments or thoughts would be greatly appreciated!
As it turns out, there is an bug deep in AIR core framework that is the root cause of this issue. Adobe has confirmed the bug, and they are working on a fix for the Cyril (AIR 3.3) release. The status of the bug (#3089755) can be viewed in the Adobe AIR bug list.
In the short-term, I was forced to detect Windows messages that were being consumed by the SteamOverlay, and pass on fake messages to prevent AIR from locking up. I accomplished this by using the Windows API SetWindowsHookEx along with the WH_DEBUG and WH_GETMESSAGE hooks. This is definitely not a desirable approach, but was needed in the short-term until Adobe releases a fix.
I code in REALbasic.
Whenever I receive an IM via iChat, iChat runs an applescript and sends to it the last message received. I need to somehow forward this message as a string to the app I'm writing in REALbasic. REALbasic is able to respond to AppleEvents but I don't now how to implement this or if I'm even in the right ball park.
Any advice?
Unfortunately I haven´t used RB in ages, but maybe the following link (just a quick google) might be a starting point?
http://www.106automation.com/page2/RB/RB.html
(the link to download the example files is actually the title of the page, so click "REALBasic & Applescript")