Setting focus to next focusable widget ?

[nicolas...@gmail.com]

Hi,

i'm trying to set focus to the next focusable widget when pressing
ENTER but i can't find any information on the subject.

Am i going blind or is there really no way to do that ?

Nicolas.

[Graham H]

(I presume you need to use ENTER rather than the usual TAB for a
reason.)

One way to do this would be to add a keyboard listener to each of the
widgets you would like focus through. In listener detect the pressing
of the ENTER key and set the focus on the next widget.
You'll need to figure out what the next widget should be. This could
be done by storing a list of widgets.

I'm sure there are more elegant ways of doing this but this would
work.

g
h

On Apr 17, 2:59 am, "nicolas.lecl...@gmail.com"

[Reinier Zwitserloot]

There's no way to say 'go to next focusable widget' in javascript (and
thus, no way in GWT). So you'll need to have an ordered list of
widgets. To catch the enter key, use the onKeyDown (not onKeyPress).

On Apr 16, 4:59 pm, "nicolas.lecl...@gmail.com"

[Jason Essington]

I just solved this problem in a project That I'm working on ...

the first issue is defining "next" I used taborder for that. This
way, the behavior can be the same with the default key (tab) as it is
with your added keys (enter / return).

Then add your focusable widgets to a list in their taborder.

Finally your keyboard listener should also check to see if shift is
pressed! (shift enter should go to the previous widget the same way
that shift tab does)

look up the sender in the list, then set focus on the next or
previous widget in the list.

-jason

[Reinier Zwitserloot]

Jason, when you say 'taborder', do you mean you explicitly set a
taborder on all your widgets, or do you mean there is some way to
figure out tab order even if widgets don't all have an explicitly set
one? In the second case I'm very interested.

On Apr 17, 8:05 pm, Jason Essington <jason.essing...@gmail.com> wrote:
> I just solved this problem in a project That I'm working on ...
>
> the first issue is defining "next" I used taborder for that. This
> way, the behavior can be the same with the default key (tab) as it is
> with your added keys (enter / return).
>
> Then add your focusable widgets to a list in their taborder.
>
> Finally your keyboard listener should also check to see if shift is
> pressed! (shift enter should go to the previous widget the same way
> that shift tab does)
>
> look up the sender in the list, then set focus on the next or
> previous widget in the list.
>
> -jason
>

[Jason Essington]

In my case I explicitly set tab order on all my widgets that I expect
to gain focus.

The second case, I've not found a solution for, but if someone has
one I'd be interested to hear it as well.

-jason

[Reinier Zwitserloot]

Actually, opera offers a large host of 'computedXYZ' properties that
allow you to inspect what the browser has determined is the
appropriate 'default'. It works for CSS styles (e.g. you can get
figure out if an element is block or inline as default rendering model
simply by asking for the computed value of the display CSS element),
it might work for taborder. It's totally not browser compatible and
I'm not even sure if taborder has a computed equivalent. That's the
only thing even remotely relevant that comes to mind.

Bit of a shame javascript doesn't have a method for this :/

[Amit Kasher]

Reinier,
Why do you recommend using onKeyDown instead of onKeyPress? The
onKeyDown does provide a better response to the user, I think, but
using it will cause the widget to which the focus is set to accept the
corresponding onKeyUp and onKeyPress which may trigger something else
if these events have implemented handlers on this ("next") widget.
Using DeferredCommand will solve that, actually, so perhaps onKeyDown
is a good idea after all.
Still, is there a different reason other than improved UI behavior?

[Jason Essington]

Actually, I have a utility in my Effects framework to query the
computed value for a css property, and it works cross platform,
however I'm not sure that taborder actually qualifies as one of those
"computed values".

It may be worth investigating however.

-jason

[Jason Essington]

you'll need to capture the keypress, and when it is one that you are
looking for, cancel the event! otherwise, the browser will still
attempt to perform its default behavior.

-jason

[Reinier Zwitserloot]

MSIE6 (and probably MSIE7) sends to onKeyPress ONLY those keys which
can be represented with a character. No tab, no enter, etcetera. Hence
you'll need to hang on onKeyDown.

Also, an enter won't do anything anyway, unless you have a textarea.
That would require more work.

[Samyem Tuladhar]

I've been generally using JNSI to call this piece of jQuery code:

        var inputs = $(event.target).closest('form').find(':input:visible');

        inputs.eq( inputs.index(event.target)+ 1 ).focus();        

That seems to work for me.