Re: [XaraXtreme-dev] Galleries and focus handling

[Phil Martin <phil@xxxxxxxx>]

On 3 May 2006, at 11:50, Alex Bligh wrote:

> --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.
Yup. Just checking whether policy can be implemented easily.

> 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).
Yup. This is a good point but we just need to consider whether there  
are any real-world cases that need the more flexible approach. I'm  
thinking maybe the rule could recommend grabbing keypresses in  
logical groups but not insist on it.

Phil