Tab taking keyboard focus away from applet...HELP!

[kwatson]

We are using an embedded applet for data entry purposes.
Occasionally, a user will hit the tab key, and bad things happen.

A string of spaces are entered into the applet, focus goes back to the
browser, and then the user starts hitting backspaces, etc trying to
remove the spaces they just stuck in, and suddenly find themselves
booted out of the web application and having to start over.

I have been tasked with preventing this behavior by keeping the tab
key from giving focus back to the browser. While this seems to have
been no major problem to deal with in Firefox, IE6 & IE7 are both
proving to be my undoing, and the IE browser is the one this HAS to be
fixed in.

We are using the Sun JRE 1.6.0_03 in IE for applets.

Here are some of the things I have tried thus far without success.

// Try 1:
SwingTerminal.class.getMethod("setFocusable", params).invoke(this, new
Object[]{new Boolean(true)});
SwingTerminal.class.getMethod("setFocusTraversalKeysEnabled",
params).invoke(this, new Object[]{new Boolean(false)});

// Try 2:
Set<AWTKeyStroke> forwardKeys =
this.getFocusTraversalKeys(KeyboardFocusManager.FORWARD_TRAVERSAL_KEYS);
Set<AWTKeyStroke> newForwardKeys = new HashSet<AWTKeyStroke>(1);
newForwardKeys.add(AWTKeyStroke.getAWTKeyStroke(KeyEvent.VK_TAB, 0));
this.setFocusTraversalKeys(KeyboardFocusManager.FORWARD_TRAVERSAL_KEYS,
newForwardKeys);

// Try 3
SwingTerminal.class.getMethod("setFocusTraversalKeysEnabled",
params).invoke(this, new Object[]{new Boolean(false)});

// common to all attempts
// inside my key event processor
if ( evt.getKeyCode() == KeyEvent.VK_TAB )
{
if ( evt.isAltDown() != evt.isControlDown() )
{
evt.consume();
}
}


Debugging statements tell me that my key processor is running, however
evt.getKeyCode() is not equal to KeyCode.VK_TAB.



Can anyone provide me with some insight on how to keep the tab key
inside the applet within IE?

 

[Andrew Thompson]

We are using an embedded ..
(ick)

..applet for data entry purposes.

Have you considered 'freeing' this applet from the browser
and allowing it to be free-floating*? It would fix problems like..

Occasionally, a user will hit the tab key, and bad things happen.

..this.

* Launch it using JWS. Here is an example.
<http://www.physci.org/jws/#jtest>
(Note - the server was not available the moment I tested
that link, but it should be back shortly..)

--
Andrew Thompson
http://www.physci.org/

Message posted via JavaKB.com
http://www.javakb.com/Uwe/Forums.aspx/java-general/200712/1

 

[kwatson]

Have you considered 'freeing' this applet from the browser
and allowing it to be free-floating*? It would fix problems like..

This was a free-floating part of our users tool set a month ago.

We went to the embedded applet because the users were having far to
many windows/apps running and it was getting difficult for the users
to find the correct open window quickly. So we have developed a web
based dash board for our users where all of their needed folders and
applications are available from a single page using divs/visibility,
etc.

As it happens, this applet is the center piece of the new dashboard
application. The response from management and users on this new
interface has been overwhelmingly positive ( a change that people were
begging for! ). I think they would string me up if I were to tell
them we have to go back to multiple windows.

Thanks for the suggestion though...any thoughts how I can resolve this
an leave the applet embedded?

 

[Andrew Thompson]

This was a free-floating part of our users tool set a month ago.

We went to the embedded applet because the users were having far to
many windows/apps running and it was getting difficult for the users
to find the correct open window quickly. So we have developed a web
based dash board for our users where all of their needed folders and
applications are available from a single page using divs/visibility,
etc.

A JFrame can hold tabbed panes, cardlayouts, splitpanes or
scrollpanes (the first things that jump to mind) that each
contain different GUI elements, including entire Applets
(though a workable applet context is a little trickier, it is
also possible). As well, components can be shown or
hidden using setVisible().

What I am getting at, is that everything that can be done
by embedding multiple applets in a dynaminc web page,
can be done by including the same elements in a Java
based root pane. And it can be done more reliably, without
worrying about the vagaries of browser manufacturers.

As it happens, this applet is the center piece of the new dashboard
application.

Your programming a ..car? What is a 'dashboard application'?
I did a quick Google and the range of programs that seemed
to be returned suggested it was no more than a cute 'marketing
ploy' to make a program sound (more) important (than it is).

...The response from management and users on this new
interface has been overwhelmingly positive ( a change that people were
begging for! ).

Despite its obvious problems with tabbing?

.. I think they would string me up if I were to tell
them we have to go back to multiple windows.

They don't. But..

Don't 'tell them' anything. *Show* *them*. A workable GUI
paints a thousand words.

Heck, tell them that while working on the solution to the
'real problem' you can offer the free floating root component
as a 'temporary fix'.

Once the user has a desktop shortcut to the new (fully
functional) 'combined UI in a frame' - I think they will be a
lot less anxious to get the web page fixed.

Thanks for the suggestion though...any thoughts how I can resolve this
an leave the applet embedded?

<dws>Beg the browser manufacturer to change their mind
on tab behaviour?</dws>

But seriously, no. I have spent too much time trying to fix
arcane problems with applets in the past - I'm over them.
Just thought I'd throw in the suggestion of Java Web Start
as the sensible (OK - 'the only logical') alternative.

Now - turns pointedly to all the people who are 'fans' of
applets. Have *you* lot got any useful suggestions here,
or are you just sitting back, waiting for the next time you
can chime about how I'm so 'prejudiced' against applets?

 

[kwatson]

Thanks again for your comments Andrew. I appreciate them even if you
are anti-applet.

A JFrame can hold tabbed panes, cardlayouts, splitpanes or
scrollpanes (the first things that jump to mind) that each
contain different GUI elements, including entire Applets
(though a workable applet context is a little trickier, it is
also possible). As well, components can be shown or
hidden using setVisible().

What I am getting at, is that everything that can be done
by embedding multiple applets in a dynaminc web page,
can be done by including the same elements in a Java
based root pane. And it can be done more reliably, without
worrying about the vagaries of browser manufacturers.

Ok, I get what you are saying, but this is the only applet in the
lot!

The remainder of the web page is all basic web stuff, just from
various sources...like:
* views into shared file folders on various internal servers
using iframes
* internal and external informational web pages
* an AJAX based one-way messaging system
* etc...

I would prefer not to have to rework everything in the site to run
under Java if I can avoid it.

Your programming a ..car? What is a 'dashboard application'?
I did a quick Google and the range of programs that seemed
to be returned suggested it was no more than a cute 'marketing
ploy' to make a program sound (more) important (than it is).

No, it is not a car, but it functions much like the dashboard in your
car. The basic purpose for your vehicles dashboard is to present you,
the user, vital information about the operation and status of varying
systems while in the drivers seat. Ever tried to check the oil
pressure, fuel level, coolant temp, voltage or speed of an operating
vehicle without a dashboard?

This web application serves the same purpose, information from various
systems that are critical to the proper and successful completion of
the users job. Thus I called it a dashboard...but I am now getting
off topic.

Despite its obvious problems with tabbing?

Yes, the users are normally trained to not use the Tab key within the
applet. This really only occurs a few times a day, but it is an issue
that was raised when it happened to a user who was trying to service
an "important" client. I was told that the "important" client raised
a stink with some of our execs, and the order came down to fix
it...regardless of frequency of occurrence, etc.

Now - turns pointedly to all the people who are 'fans' of
applets. Have *you* lot got any useful suggestions here,
or are you just sitting back, waiting for the next time you
can chime about how I'm so 'prejudiced' against applets?

Way to go! Throw down the gauntlet. Issue the challenge. Anyone out
there willing to rise to the task?

 

[Richard Maher]

Hi K,

I've only ever worked with blind Applets so this post is probably of limited
use, but I cannot bare to see you treated so badly, so in the absence of an
Applet-friendly newsgroup here goes:-

We are using the Sun JRE 1.6.0_03 in IE for applets.

Here are some of the things I have tried thus far without success.

FWIW, have you tried tackling it from the JavaScript side? What happens if
you have an "onkeydown" event on the Applet Object and "return false" if
the TAB key is pressed? (onblur set focus back?)

Alternatively, a quick search of the web suggests that you should be
invoking the setFocusTraversalKeysEnabled(false) method on the Applet
itself, in the init or start methods - have you tried that?

No, it is not a car, but it functions much like the dashboard in your
car.

For anyone else who have trouble conceptualizing a dashboard, here's a
pretty good example:-
http://examples.adobe.com/flex2/inproduct/sdk/dashboard/dashboard.html
or this: -
http://examples.adobe.com/flex3/labs/dashboard/main.html#

The new FABridge functionality also looks very useful for driving everything
from the JavaScript side if that be yer preference.

So just in case you're running out of gobby Aussies who can't help but tell
you (and the whole world) how to run your lives, my suggestion is that you
drop the Applet graphics and use Flex Charting instead.

Come to think of it, you've been told here many times that "SUN is
deprecating Applets!", "Web browsers will never last", Steve Jobs says "Java
is a great big ball and chain", No iPhone support, No native Windows
support; maybe it's all adding up? Maybe if I was a dedicated professional
twat then everytime someone comes here and asks "Hi, I'm at A and I'd like
to get to B please" I could say "You'll never get to B starting from A; All
you Applet lovers are all going to hell!".

OTY.

Cheers Richard Maher

 

[Andrew Thompson]

Richard Maher wrote:
...

I've only ever worked with blind Applets ..

What exactly is a 'blind' applet, and how does it differ from an
applet with '20/20' vision?

...so this post is probably of limited
use, ..

Puhh! Enough excuses already, get to the solution/suggestion!

...but I cannot bare to see you treated so badly, so in the absence of an
Applet-friendly newsgroup here goes:-


FWIW, have you tried tackling it from the JavaScript side?

Classic. I was just waiting for somebody to suggest JS as a helper.

FWIW - all sarcasm aside - I think that might be the best/only
soutlion to the problem as stated.
...

Alternatively, a quick search of the web suggests that you should be
invoking the setFocusTraversalKeysEnabled(false) method on the Applet
itself, in the init or start methods - have you tried that?

Unfortunately (my) experience suggest they only have an
effect if the applet *already* has input focus. Admittedly
though, I have no 'test case' for people to surf to, & prove
me wrong.

For anyone else who have trouble conceptualizing a dashboard, here's a
pretty good example:-
http://examples.adobe.com/flex2/inproduct/sdk/dashboard/dashboard.html
or this: -
http://examples.adobe.com/flex3/labs/dashboard/main.html#

(abashed) ok OK! I might look over them later.

So just in case you're running out of gobby Aussies ..

..who can't help but tell
you (and the whole world) how to run your lives, my suggestion is that you
drop the Applet graphics and use Flex Charting instead.

Are you *serious*? That is very funny. ;-)

Come to think of it, you've been told here many times that "SUN is
deprecating Applets!",

By who? When? If you don't produce links to actual posts*,
I will consider you a lier/mistaken.

* I have said similar things in the past, but have never gone so far
as to say that Sun has *deprecated* applets.

OTY.

Over to You? That is an obscure one!

Oh, and since I've spent the time (and the bandwidth of other people)
to kick back into this thread, I'll mention another thing ..

You (the OP) mentioned earlier that some of the content the app.
needs to display, comes from web pages, and that was another
reason you felt the app. could not be
a) Entirely contained within a JFrame (or equivalent) and therefore..
b) Represented in pure Java.

A thought occured that you might use an 'embedded' browser
within Java - JDIC supplies an API that will allow you to do that
on Win/*nix systems at least. OTOH - that does lead to more
're-engineering' of the app. than if it had been a single, self
contained applet as your first post suggested.

--
Andrew Thompson
http://www.physci.org/

Message posted via JavaKB.com
http://www.javakb.com/Uwe/Forums.aspx/java-general/200712/1