Multiple Events Fired in Table

[JDarsley]

Describe the bug

Clicking on a Toga table is firing the on_select function twice.

Example code (the preview feature suggests that the non-indented lines of code aren't formatting correctly):

import toga

class MyApp(toga.App):

    def startup(self):
        self.main_window = toga.MainWindow()
        self.main_window.content = toga.Box()

        lstDetail = [
            {"Detail": "Subject Heading"},
            {"Detail": "Date and time"},
            {"Detail": "Note text"}
        ]

        self.tblNoteDetails = toga.Table(
            headings=None,
            accessors=["Detail"],
            data=lstDetail,
            on_select=self.onSelect,
            flex=1
        )

        self.countOnSelect = 0

        self.main_window.content.add(self.tblNoteDetails)
        
        self.main_window.show()

    def onSelect(self, widget, **kwargs):
        self.countOnSelect += 1
        print(f"\nSelect handler - call {self.countOnSelect}")
        print({widget.data[0]})
        print({widget.data[1]})
        print({widget.data[2]})
        
if __name__ == '__main__':
    app = MyApp("Events", "org.jd.events")
    app.main_loop()        

Steps to reproduce

1. Open a console.
2. python events.py
3. Click on any row in the table.
4. Click on any other row in the table.

If you first click on one of the rows shown in the table, the event function will run once. See console messages. Now click on another row, and the console will show that the function has run twice more - three times in total. Click another row, two more calls to the function.

Expected behavior

Each click on the table should fire the event function just once.

Screenshots

The console shows that the event function has run three times after clicking the table only twice.

Environment

• Operating System: Windows 11
• Python version: 3.12.6
• Software versions:
  • Briefcase: 0.3.22
  • Toga: 0.5.0
  • ...

Logs

Additional context

No response

[freakboy3742]

Thanks for the report - I can confirm I can reproduce this behavior; and your analysis that the event should only fire once is definitely correct.

The problem appears to be Windows specific, and is related to the changes introduced in #2956 to support keyboard navigation in tables.