Now that you have seen the Bonds problem happen in a real application, I'm going to explain to you
why we have this problem.
Let's have a look at the signal from the button.
OK, let's say the signal is low first and then you press the button and everything goes well.
The signal will go higher.
And you know that the button has been priced when you monitor it.
Now, when you release the button, if everything goes well, the signal will go to low.
And that's quite what you would expect from the button.
OK, and that's what you had in most of the cases in the previous experimentation.
So you press the button again, the signal goes to high and then you release.
And what is happening here, as you can see when you release the button, this time the signal is bouncing
from low to high and high to low a few times before finally going to low.
It can happen here when you release the button, as in this example, but it can also happen when you
press it so easy on this part of the signal, either when you realize or when you press it.
So this is what happens when the button bounces.
This is purely a physical issue from the button sensor.
OK, when you press the button, the hardware part that connects the wire together can bounce a few
times before being stable.
That's when you read the button state in your code.
You also see these buttons and the number of buttons is going very K can be zero bouncing in a good
situation or just one, two, three, etc. and this can lead to behavior you don't want.
For example, if you want to increase a counter whenever you release the button, then we have to bounce.
The content may be incremented by more than one every time you release the button, which makes your
application not working correctly.
Or if you want to toggle an entity, which is an application we do later in the section.
And I just talked about it a little bit before.
Well, imagine that the button bounces three times like here on the screen.
In this case, after being told a few times very quickly, the state of the editing would be the same
as it was before you released the button.
Note that there are some applications where you don't really need to worry about the button bouncing.
For example, in the previous activities, we have made a project where an entity will be pulled on
if the button is priced and proud of.
If the button is not pressed, well, the buttons will still happen, but it will not modify the behavior
of your project.
The real problem is when you need to do something and the trigger for that is the change on the signal,
not the signal itself.
Fortunately, there is a solution to that issue.
By modifying the code a little bit, we will be able to remove the balance effect.
The principle is quite easy.
After we noticed that there is a change of state, we are going to simply ignore all of the changes
for a given amount of time.
So here on the diagram, you can see that when we have the balance problem, if we ignore all changes
for this amount of time here with the Green Arrow, then we don't take into account all the bounces
that happen.
The period during which we ignore changes is called the DBMS delay.
In your application, you will be able to choose to increase or decrease the delay so you can make sure
you don't get any bumps in your code, but also that you don't miss any real change in the signal.
And of course, to ignore the changes for the short duration, we are not going to use the delay function,
but instead the time functionalities that you have just discovered.
Now let's see how to write the code for this Diebold's functionality.