David, I don't think this is anything caused by your method of coding, and so I don't think it's anything you can control. I've noticed this tendency not to be able to interrupt Eloquence at times, when just working with programs not apps. Perhaps it's even more noticable with the voice you are using?
I suspect it's something accidentally introduced in version 9.0.0. Chip -----Original Message----- From: David [mailto:trailerda...@hotmail.com] Sent: Friday, February 06, 2015 11:44 PM To: gw-scripting@gwmicro.com Subject: Interrupting alternative voice I have noticed a small inconvenience, and hoped that someone here has an idea of a workaround. For AISquared, is there any reason why this happens, and could there be a fix implemented into the API? Several developers on this list, have been using either the Keyboard or Mouse voice, for speaking out messages in their apps. One benefit of that approach, is the chance to alter the voice parameters, without affecting the general speech output of the screen reader. I have set my screen reader to interrupt on all keystrokes. Typically, I would hit things like Ctrl or Shift-keys, to interrupt any ongoing speech from the system. But when I let my app send a number of strings to one of the alternative voices - that is, Keyboard or Mouse - I can hit ctrl a thousand times, without any interrupting taking place. Will I need, to have any further lines of coding implemented, for the interruption to be effectuated also under the alternative speech output? Or, at least, is there any piece of code, that would ensure this kind of interruption, that I could insert more like an extra measure of "security"? First on the topic, AISquared, one wish for upcoming versions of the screen reader and its API, would be for us to have a chance of assigning different synths for speech output. We then would not have to stick to one and same synth, for all three voice alternatives. You even could let us have a specially designated channel, named things like MessageSynth, which could be set to any synth installed on the current system. By setting that channel, and then sending a string to it, the synth would be activated, speak the string, and then deactivated. Of course, I don't know if it needs to be fully activated and deactivated on each call, maybe you can somehow put it into some kind of sleep mode, which may shorten the invoking time for each call. Would greatly have expanded the capabilities of our apps. Thanks for any feedback. -- David
