Dialogs and popup edit controls: Update

[ATS]

[followup from positing in wxwidgets.general group]

I've been testing an implementation of EVT_CHAR_HOOK along the 
lines we discussed and it seems to work OK. 

However, looking at the problem again, after doing 80% of the work :( , 
I can see some drawbacks and an IMHO better solution:

Drawbacks:

- By passing EVT_CHAR_HOOK to the focused widget instead of the TLW window, 
it is more similar to other key events (excepts it propagates up to parent
if not processed). So... there are now 4! different events potentially sent 
to a widget with focus:
  - wxEVT_CHAR_HOOK 
  - wxEVT_KEY_DOWN
  - wxEVT_CHAR 
  - wxEVT_KEY_UP 

- On a small device this could possibly reduce responsiveness. 

- I think EVT_CHAR_HOOK was first written just to give a TLW the first go
at a key press. With the new scheme, this is not always so. 

- The whole solution to handling popup edit controls that want to process
WXK_ESCAPE/WXK_ENTER becomes distributed and not so easy to follow.


The simpler solution would be like this:

- Introduce a function wxCaptureKeyboardFocus(). This indicates that
a widget has keyboard focus until it explicitely gives it away (or
closes). 

- When showing the popup text control, it grabs keyboard focus. 
This is intuitive enough. 

- In wxDialogCmn::OnCharHook(...), we check if some control has grabbed 
keyboard capture and then let the keyboard event be processed as usual.
(this works without using wxKeyEvent::AllowNextKeyEvent() since wxDialogCmn
is the base class and skipping the event has the same effect here. If 
no widget has keyboard capture, then the dialog can process the key as 
it wishes. 


Making wxEVT_CHAR_HOOK a general key event sent to each focused child 
widget complicates things a bit I think. Receiving 3 or even 4 different 
key events per key press is more than needed. Try explaining this to a 
new comer... (probably, with quite some effort and significant testing,
wxEVT_CHAR_HOOK and wxEVT_KEY_DOWN could be merged).


To me the keyboard capture concept is easier and less likely to cause
unexpected problems. It is not as general as the 
wxKeyEvent::AllowNextKeyEvent() approach. Maybe I'm missing something, 
here, but I don't quite understand where that generality is used.

Regards
// ATS.