Re: [XaraXtreme-dev] Galleries and focus handling

[Alex Bligh <alex@xxxxxxxxxxx>]

--On 03 May 2006 11:40 +0100 Phil Martin <phil@xxxxxxxx> wrote:

> > 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?

I'd rather not do it in the control itself or we would need to subclass
every control. However, it's possible to intercept keypresses at the
dialog level (which is I think what Luke is doing at the moment). We
can also intercept without subclassing on a global basis using the
same technique as wxEventBlocker (i.e. using FilterEvent) if it's
really necessary.

However, I think we should keep the implementation away from the policy.
Even if we could pass on a different set of keys if they were unused, would
we want to? For instance, in a readonly combo (or a drop down list), the
letter keys select the item with that first letter, the delete key does
nothing. In a writeable combo, the delete key deletes a letter in the
edit field. Are we really saying we want delete to be passed to the
document in the former case, and not in the latter case? I think this
would be undesirable. Best have controls with flashing carets etc
take ALL key events, or have no flashing caret and they take none.
That's actually pretty close to Luke's current implementation (+/-
modifications to the content of the list as to which controls can
really take focus).

Alex