[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]

Re: [XaraXtreme-dev] Galleries and focus handling

Phil Martin wrote:



On 3 May 2006, at 11:51, Luke Hart wrote:


Phil Martin wrote:



On 3 May 2006, at 10:07, Luke Hart wrote:
2. A modeless control owning the focus uses only the keypresses it needs (see rules 3 & 4) and passes all others on through a chain in this order: control, control parents (recursively), active view, active document, application.
This isn't quite the case at the moment. For example if you give an edit box focus, it takes all input. There is no way (currently) to tune what keys a control instances takes, and only rudimentary tuning of control types (either a type of control takes all or takes none)
I was assuming that individual keypress events could be claimed or passed on by handlers choosing to call event.Skip() or not. Is that not the case? 

Phil
No, events can be eaten by native (GTK) controls before the wx frame work even know about them. In order to get all the events I need to handle them at the application level, which means I pass them on or not based on the type of control. If we need fine grain control I may have to have someway of overriding whether a control instance gets keys or not (or going further allowing a callback to allow a decision as to whether a particular key should be passed or not).
Can you give us an example of when a GTK control eats a keypress event before we see it? How does your application level handler get to see them before the control? 

Phil
I think the problem was something bazar like a check-box putting the key message through the IME and then not passing them on.
The application has a keyboard hook which seems to be able to veto messages getting to the control. To be honest the wx key handling doesn't seem as clean as it could be and I had to work around its foibles.
Having said all of that I can now see an easy way of re-using dlgevt handler to force focus back to the drawing when dealing with non-keyable controls. 

   Luke