@Pecan :
Since already 2 users started to have problems since the above mentioned changes, could it be it's purely because of this. They probably already redefined ctrl-Q (If they already done this in the first place?) and only now it seems to become a craashing problem ;-)
The problem has been there since day one. There's a warning in the code by the original authors that Alt-F4 (his original quit key) caused crashes on termination.
I decided to delay doing anything about it in CodeBlocks until the situation proved his comments.
It's true, I changed the code to use Connect/Disconnect rather than PushEventHander. This was to avoid leaking event handlers when windows were closed without giving plugin notifications. Without notifications I had to leak the event handlers rather than crash the system.
I fixed the leaks. Then the original authors problem became my problem.
So I've temporarily resorted to the same hack the original authors did. Namely, ignore *additional" key definitions to the quit menu item.
Note that you *can* redefine the quit menu key. But "additional" definitions other than the first will be ignored. The crash does not occur on the first key because the first of the three key definitions is never seen by the keybinder event handler. Wx always traps its own menu key and dispatches it's own event handler.
What I don't understand yet, is why keybinder is being re-entered after it's been unloaded from memory. The reports on the forum would indicate that an errant branch from stack corruption is the culprit. This is just a guess. Ergo, a very low stack clobber is occuring somewhere in keybinder/widgets between the time keybinder gets the quit key and CB unloads and does a final return to widgets. Then widgets executes the clobbered stack, branching back into where keybinder "used" to be.
This is going to be hard to find. Thus I decided on the "ignore" hack to give me time to figure it out. I'd rather cripple the additional quit keys than leak the event handlers.
your thoughts?
regards,
pecan