Why does my counter system not work?

[Baran_Galocy]

Please forgive my density but I cannot solve this simple issue. When my call settings button is clicked, the variable, GlobalAtmoCount = 0. In my simple mind, the +1 portion should restrict the text to being spoken only once and not repeatedly while the contition is true. I change the globalAtmoCount back to zero when the screen 1 backpress button is clicked. Due to uncertainty, I tried three ways and all three configurations speak the text repeatedly.

So, if I were to phrase this as a question and not a presentation, how the heck can I prevent the TextToSpeech1 from repeating without clicking the Call_Settings button again? I would really appreciate any assistance. I am just to close to this and it is too simple for my overthinking mind.

[Taifun]

How does your AfterSpeaking event look like meanwhile?

And why don't you try @ABG 's suggestion?

How do you set min and max values for alarms?

Here's a sample app that shows how to queue up speech and have it announced serially without overlap. [blocks] speech_queue.aia (21.6 KB) Instead of speaking directly, feed the text to the blabber procedure. It handles the speech.

Taifun

[Baran_Galocy]

Here I am answering myself. I could delete this post but it may help. I was placing the counter block in a section that only occurred once. It was the After.Speech block that required the counters, as shown here:

[ChrisWard]

Hi Brian

It is best not to use the Button 'click' block as it is easy to inadvertently double click. Instead, use the Button 'up' block.

[ABG]

My working sample included two procedures for good reason.

Procedures are the underwear and diapers of software.

They conceal and contain a lot of unpleasant stuff.

My procedures encapsulate the queueing logic for speech output.

So don't go commando in polite company.

[ABG]

On rereading your post, I realize I have not addressed your problem.

You are asking how to suppress repetition of error announcements.

To do so, you would need to keep two data structures:

• a policy dictionary, with announcement text values as keys, and minimum announcement delay intervals as values. Milliseconds are easiest.
• an announcement history scoreboard dictionary, with those same announcement text values as keys, and for values the Clock1.SystemTime of when that announcement was last issued (or 0 if not yet).

The policy dictionary balances the need to announce against the need for a period of peace and quiet in between announcements.

The basic idea would be to have the announcing procedure look up the message in the announcement history dictionary, and test current (Clock1.SystemTime - last issued SystemTime from the announcement history dictionary) to see if it exceeds the matching policy delay milliseconds value.

If the cool down period is over, make the announcement and update the history dictionary, otherwise ignore the request entirely.

P.S. See

How to stop notification loop/ or set a duration when only to notify

Here is a general purpose notification limitter. It is built into an app for people driving their kids somewhere. (The kids are instructed to gripe through the app.) [sample run] [blocks] [Designer] notification_limitter.aia (3.6 KB) [to notify text do] [when any Button.Click component notAlreadyHandled do] [initialize global One_hour to]

for prior work.