Strange tab behaviour when madExcept dialog showing
Posted: Thu Mar 05, 2020 2:33 am
We had a strange report about funny chevron characters turning up in our edit controls rather than tabbing to the next control but it only happened intermittently.
We eventually tracked it down to only happening when there is a madExcept exception dialog showing which hasn't been actioned yet i.e. continue, restart, close etc. not chosen.
I'd always assumed those madExcept dialogs were modal but they aren't which makes sense since they are running on a different thread and message loop.
If I click to move the keyboard focus back to one of our controls and press tab or shift tab, I get a chevron character (how we indicate tab in strings) rather than tabbing to the next or prior control.
If I close the madExcept dialog by selecting continue, pressing tab and shift tab now work again as normal.
We use our own edit controls rather than stock Delphi TEdits and I thought it might be something we are doing, so I built a simple project with a pair of TEdits and a button which generates an Access Violation.
When the madExcept dialog is showing and I press Tab, rather than moving between the edits, I get a windows beep. So again, the control is getting a TAB keypress it doesn't expect .
I wondered if the madExcept dialog was putting in place some kind of message filter and changing the handling of WM_GETDLGCODE messages but I can't see anything so I'm at a bit of a loss.
Any ideas where else to look in the madExcept dialog code to avoid this?
We eventually tracked it down to only happening when there is a madExcept exception dialog showing which hasn't been actioned yet i.e. continue, restart, close etc. not chosen.
I'd always assumed those madExcept dialogs were modal but they aren't which makes sense since they are running on a different thread and message loop.
If I click to move the keyboard focus back to one of our controls and press tab or shift tab, I get a chevron character (how we indicate tab in strings) rather than tabbing to the next or prior control.
If I close the madExcept dialog by selecting continue, pressing tab and shift tab now work again as normal.
We use our own edit controls rather than stock Delphi TEdits and I thought it might be something we are doing, so I built a simple project with a pair of TEdits and a button which generates an Access Violation.
When the madExcept dialog is showing and I press Tab, rather than moving between the edits, I get a windows beep. So again, the control is getting a TAB keypress it doesn't expect .
I wondered if the madExcept dialog was putting in place some kind of message filter and changing the handling of WM_GETDLGCODE messages but I can't see anything so I'm at a bit of a loss.
Any ideas where else to look in the madExcept dialog code to avoid this?
