I have been looking into the bug (#417) regarding the ESC key. You can see the problem if you

[]open the Partner Find screen[/:m]
[]drop down the combo box at the top right where you choose one of PERSON, FAMILY, CHURCH etc[/:m]
[]with the list dropped down press the ESC key[/:m][/list:u]
The whole screen closes rather than just the combo box closing up! And by the way, that ComboBox is not one of our special derived classes - it is a plain Windows Forms one.

But it gets better! If you re-open the screen and simply press ESC, the screen does not close at all.

It has taken me rather a long time to get to the bottom of this because I had assumed that the cause of this bug was going to be something completely different.

So this is what happens ....

We have a handler in our base class PetraForm that handles the KeyDown event at the form level. It takes action only on ESC and F1. It is our code that is closing the form based on this PetraForm event. Now usually all the controls on our forms capture the KeyDown event for the ESC key and handle it, so nothing ever gets to our Form-level handler. But if the list of a plain ComboBox is dropped down it does pass on the KeyDown event to the Form - and our code kicks in. Oh, I should also add that the Country drop down on the Partner Edit screen, which also has the same issue with ESC closing the form is not directly a TCmbAutoPopulated but for some reason is a dedicated user control. If it were a TCmbAutoPopulated it would not give the same problem.

So in summary I think the problem occurs anywhere where we have a screen that implements IFrmPetra and contains a Windows.Forms.ComboBox or our special TUC_CountryComboBox. You might think this would be many screens but actually it is very few (or maybe just this one).

There are multiple ways of fixing this issue. Several of these I have proved to work, so the question is which way do we prefer?
1. Create a derived class from ComboBox that we always use in place of the standard one - so everywhere we currently use a ComboBox we use one of ours. This would work but seems like it should not be necessary and really could end up being messy. And there really is nothing to stop people using a ComboBox on a specialised dialog screen in the future.
2. Add an override for ProcessCmdKey() to any screen where the problem occurs and check if the ESC key was pressed and whether any ComboBoxes on the form are 'DroppedDown'. I have implemented this and it does indeed solve the problem. The disadvantage is that the fix is screen-specific and we might have - or might add - a screen that would also need the same fix. However it may be the solution that we decide to use because there is nowhere else that needs it and it doesn't change any other existing code.
3. Modify the standard auto-generated implementation of the Form_KeyDown interface method so that it does nothing when the ESC key is pressed. This is my preferred solution although it sounds rather dramatic! The reality is that - at the moment - the method never gets called. If it did, every screen would close when the ESC key is pressed, but every control on our screens swallows the ESC key down action and it never bubbles up to the Form itself. When the interface code was originally written the author must have intended that ESC would close any screen, but in practice this does not work. Furthermore, as a personal opinion, I don't think I would expect ESC to have that effect on our screens. (Screens that are modal and have a cancel button do automatically respond to ESC without needing our code, so screens like that are not an issue). As an aside the only other thing our Form_KeyDown handles is the F1 key - and that does nothing either because it is not implemented!
Notice that the fix for this is nothing to do with our existing comboBoxes.

So the main purpose of this post is to ask the various people who have design authority what the plans are for OP and the use of the ESC key. If we don't want the ESC key to close screens then my option to remove it from the interface implementation makes sense, because a) 99.9% of the time it doesn't do anything there anyway but b) on the 0.1% of the time where it does do something it isn't what we want it to do! On the other hand, if there is a plan to make the ESC key close our screens (I think there might be a Mantis case to get this working??) then the way to make that happen is not to use the KeyDown event but to intercept the ProcessCmdKey() in the autogenerated code and check for the ESC key in there. If we do that we can include the code that I used in suggestion #2 above to deal with the case where a ComboBox might be open.

I will not check in anything on this Mantis case until I get some feedback. Please ask if I haven't made anything clear.

Alan