Desktop TabPanel fires spurious TabChanged events and misreports user interaction

Desktop TabPanel can fire TabChanged several times when a window first opens, even though the user has not selected a tab. This can run application code repeatedly, for example displaying several message boxes at startup. Some of these notifications incorrectly report pressed = True.

Changing the selection of a dropdown or another selectable control inside a tab can also fire the parent TabPanel's TabChanged event even though its selected tab has not changed.

Initial layout setup should not replay stale tab changes into application handlers. After setup, genuine tab selection changes should be delivered once, with pressed correctly distinguishing user interaction from programmatic changes. Selection changes in child controls should not raise the parent TabPanel's event.