Now this is an interesting one. The way Explorer HAT handles touch is “event driven”, and the functions you give it to handle a particular touch are squirrelled away within a list in the Explorer HAT module and run in a separate thread each time a touch event is recognised.
This means your
return True is working, but it’s sending the return value to the bit of code that polls the touch sensor chip and calls the touch functions.
Perhaps the best way to fix this is to flip the logic on its head and make your game, or application a class that exposes some functions you want to run when a button is pressed.
Let’s think about it this way:
self._guesses = 0
# Some more initialization stuff and whatnot
def handle_touch(self, channel, event):
print("Handling a touch!")
if event == "press":
self._guesses += 1
while self._guesses == 0:
print("No guesses yet!")
while self._guesses == 1:
print("One guess! Press again to exit")
my_app = My_App()
# Set up Explorer HAT to call our Apps touch handler on touch
This is a really crude example, but it shows your ( or attempts to ) how you can create a method in your class that handles touch events, and exploit the fact that Explorer HAT implicitly threads any calls to this method.
Even though your Python program is stuck running the
while self._guesses == 0 loop, when you press a button the
my_app.handle_touch method is called asynchronously ( in a thread ) and can increment
run method could contain the main logic loop, and would probably be better with something like:
# do stuff
So you can set
running to False and stop the App in your touch handler at any point.
Sorry if this is all jargon to you, but I notice you’re using classes and decorators so I’ve gone slightly techno-babble!