Change button background, wait 500ms, change it back doesn't work.

I've attached my approach for simon says.  I'm trying to do something simple which is when a button is pressed, the following will happen:

1.  The button changes color

2.  The sound is played

3.  We wait 500ms (since the sound event doesn't pause program execution)

4.  We change the button color back.

It looks like everything works except the first step - temporarily changing the button background color.

Can anyone see why?

Simon.aia

--

If you are asking for help, I recommend you to make it as easy for others to be able to help you ...

You probably will get more feedback then...

which means in your case post a screenshot of your relevant blocks...

To download the aia file, upload it to  App Inventor, open it, do some bug hunting for you, etc... this takes time, and most people will not do that...

Thank you.

--

The problem was with the clock.
I added 3 more clocks & some blocks to enable/ disable the clocks.

Simon.aia

--

Thanks for your help but why are four different clocks needed?  Logically, it seems like my approach should work.

--

Here' are the relevant parts of my program.  

--

use the Player instead of the Sound component

there is a Player.Completed event available you can use instead of your waiting procedure

see also Why is a wait procedure generally a bad idea?

--

I agree with Taifun's asessment.

Another solution might be to use the Button TouchDown and TouchUp events.

The button is touched and held down (TouchDown) , triggering a sound and color change.

(The color will stay changed until the button is released)

The button is released (TouchUp), triggering a change back to the starting color.

So no delay is required or Clock Timer.

'Here is what I came up with along these lines...

If the sound is long in duration, Taifun's suggestion of using the Player.Completed block may be best to insure that the sound effect finishes playing before changing the color back to it's original value.

SimonAlt.aia

--

Thanks for the article about wait procedures.  The main gist of the negative part is that nothing else can happen during the wait and the UI will appear unresponsive.  I don't think that 1/2 second wait that matches the sound length is really a problem here though.  I've made tons of apps and never had to use a wait before so it's not a common thing for me to do.

Anyhow, I think the player completed event is the way to go.  Thanks for your help!

--

When you decide on what approach that you will use, please show us the relevant blocks.

--

Well, I used the player completed event to change the color back. That works great.  You can press any button you want, get the highlight and the sound as you'd expect.  Trouble is, if you want to play a sequence (the test button does this at the moment), they all pile up on each other because there is no wait event slowing it down. Curious what the proper approach is to this problem.

Simon_2.aia

--

You can avoid the pile up problem by adding a couple of lists...

A queue of notes remaining to be played, 

initialized at the start button press and depleted 

each time a note ends.

A list of lists naming the player components, their sounds, and their before and after colors.

Set that list up at screen initialization time, when the components are available.

Refer to the appropriate component slot when starting or ending that sound.

--

Thanks very much for the answer.  I understand a little of what you're saying but not really.  I think this is becoming way to complicated - I'm trying to teach middle school kids here.  Starting to not like event-driven programming.  I think that's the C-programmer in me speaking out.  Going to think of another project to teach.

--

Before you quit on this, check out this similar

app that tries to sing "A Modern Major General"

using the speech block, one syllable after another.

The queueing is similar.

https://docs.google.com/document/d/1zQt7H_bsXX0Y0zmwQ1wIEESyH1YyWyYbE1HR2KYW0CI/edit?usp=sharing

--

Thanks Abraham, that document was helpful.  I modified my program to match that model and that works.  The trouble I then had was that if I clicked on a color button instead of the sequence button at the bottom, it would still call the "iterate_through_list" function which, in that case, I didn't want to do - I just wanted that one note to play and then stop.  To avoid the playing of the sequence, I added an instruction in each button click that makes the index go way over the list size (100), that causes the iterate_through_list function to not really do anything even though it's still being called.

Interesting brain exercise but a bit advanced for my kids I think.  Especially since I haven't even added any of the actual game logic...

--
You don't want your four players to automatically progress through the tune each time they end a note.

Since they are triggered by buttons, they should be single-shot.

If you devote another player, say called TunePlayer, to the context of automatically playing through a tune,

say as a user prompt, only that Player's Completed event should contain any code to walk thru a tune.

You would have to swap its next sound file in as it walks the note list.

Beware an old Player bug that might appear as a 7xx error.  It requires a 'rehearsal' phase at app startup

where all possible sound file names are loaded into Players one after another, to avoid surprising the Player at performance time.

--