Wow I just tried yours Steve, thank you! Yesterday I had a lot on my mind with my neighbor passing away. I woke up this morning and the first thing that entered my mind was, "You were wrong about the speech line being too long, it wasn't the speech line, it was the 's in date's that messed it up." So I just tried my version with just going to the SUB once and it worked. Then I tried your version and yours is better because you use the TIMER and DONTWAIT to keep the ball rolling. Thank you! I'll make yours the best one on the thread because it also doesn't need the added LCD font. Of course we could change yours so it only goes to the SUB once, but that's a bit too picky and wasted time, in my opinion.
Powershell has several options which you can use as command delimiters. quotes, single quotes, brackets all seem to work the same way, more or less, from my testing. One is a START whatever and the second is an END whatever, so things like the following are all valid:
File.Open = "C:\foo directory\foo the file.txt"
File.Open = 'C:\foo directory\foo the file.txt"
File.Open = {C:\foo directory\foo the file.txt}
Now. someone with more experience than me with Powershell scripts might be able to explain the difference in all those delimiters, but all I know is from my limited amount of playing around with them, they all seem to act the same to group the contents between them into one chunk of data.
The reason why quotes won't work in your SHELL call is from the fact that you're wrapping the whole shell statement inside quotes.
out$ = "Powershell -Command " + Chr$(34)
out$ = out$ + ...more stuff... + Chr$(34)
A set of stray quotes in the middle of those will mess up the formatting and leave powershell erroring out on what you're actually wanting it to do.
Single quotes are the same way 00 they're already being used in your code:
out$ = out$ + "$Speech.SelectVoice('Microsoft Zira Desktop'); "
Toss an additional apostrophe in there, and it'll view that as the start of your delimiter, and formatting will get all confuzzled and goof up.
Quotes won't work. Single Quotes won't work. Brackets won't work. I don't think the @ symbol works (if I remember correctly, it's got some reserved purpose as well). There's several command keys reserved for use with Powershell, and if you're going to let the user type in whatever they want to read it back to them, you'll want to research what all of those might be. Honestly, I even doubt that less than and greater than symbols will work without needing adjustment. "<" and ">" are used in html to delimit commands, and windows speech has it's own form for html which it supports, making use of the same style syntax for SSML (Speech Synthesis Markup Language).
https://docs.microsoft.com/en-us/azure/cognitive-services/speech-service/speech-synthesis-markup?tabs=csharpAs I mentioned before, Speech Synthesis in Windows is quite a powerful little tool, once you start delving into the depths of what it can actually do for you! Here's an example of some SSML written:
<speak version="1.0" xmlns="http://www.w3.org/2001/10/synthesis"
xmlns:mstts="https://www.w3.org/2001/mstts" xml:lang="en-US">
<voice name="en-US-AriaNeural">
<mstts:express-as style="cheerful">
That'd be just amazing!
</mstts:express-as>
</voice>
</speak>
Notice how we're choosing Aria to speak, and we're telling to
speak in a cheeful tone!!
And, as she says, "That'd be just amazing!" Much more than just some lame old "text to speak" robotic voice which we used to hear when talking about speech synthesis! ;)
End end point is just: Be careful with what you allow in your text to be spoken. There's a TON of reserved characters and delimiters and such that can't just be inserted and tossed around all willy-nilly wherever someone wants. If you're going to write something to let the user enter whatever they want, you'll have to validate and cleanse their input to make it suitable for the syntax which the speech synthesizer expects to find and work with.
