class IconMakerKeyHandler implements KeyListener {
private Component c;
public IconMakerKeyHandler(Component c) {
this.c = c;
}
public void keyPressed(KeyEvent evt) {
c.requestFocus();
}
public void keyReleased(KeyEvent evt) {
c.requestFocus();
}
public void keyTyped(KeyEvent evt) {}
}
What I need to do is this: Whenever the user presses ENTER or CTRL-I,
the focus will always be forced back to the JTextField component within
JPanel p1 within IconMaker (extends JFrame).
At this point I have no idea how I can ensure that whenever you press
ENTER or CTRL-I that focus will always be reverted back to the
JTextField component. Do I perform addKeyListener(new
IconMakerKeyHandler(??)) upon the JTextField, the JButton you press
after entering stuff into the JTextField, the JPanel containing both
the JTextField and JButton, or the entire IconMaker (extends JFrame)?
Thus far I've tried all of these options and focus occurs every other
key press. I'll click ENTER once, focus is lost; I'll click ENTER
again, focus is back; I'll click ENTER again, focus is lost.. etc.
Thanx
Phil
/*
* ComponentFocusGrabber.java
*
* Created on January 19, 2007, 2:13 PM
*
* To change this template, choose Tools | Template Manager
* and open the template in the editor.
*/
package GUIGraphics;
import javax.swing.JComponent;
/**
* For more information on this class
* {@link
http://groups.google.com/group/comp.lang.java.gui/browse_frm/thread/266eae0550dda678/0680228c30bf7d6d?lnk=st&q=refocus+component+java&rnum=2&hl=en#0680228c30bf7d6d
click here}
* @author Phil
*/
public class ComponentFocusGrabber extends JComponent implements
Runnable {
private JComponent c;
/** Creates a new instance of ComponentFocusGrabber */
public ComponentFocusGrabber(JComponent c) {
this.c = c;
}
public void refocus(JComponent c) {
c.grabFocus();
}
public void run() {
refocus(c);
}
}
Phil
I'm not sure I understand why you want to do this but have you
considered the InputVerifier class and shouldYieldFocus() method?
And what I, as a user of the software, immediately
needs to do once that happens is uninstall this wierd,
counterinutitive software the hell off my PC, and go
with the version made by your competitors.
It never ceases to amaze me what GUI designers
think they can get way with foisting on the end-user.
Andrew T.
Glad you don't design spellcheckers; I mean, if you're going to be
"counterintuitive" yourself, try spelling "weird" right and say "And
what I, as a user of the software, WOULD IMMEDIATELY NEED TO DO.."..
then I can take you more seriously as a rather nasty and unfortunately
counterproductive source of Java knowledge.
All that aside, I got what I wanted to work, basically, it's the same
as the Javascript element.focus() method to force focus back onto the
JTextField in case the user entered either an incorrect URL, a
non-image-producing URL, or something really "wierd".
> counterinutitive software the hell off my PC, and go
> with the version made by your competitors.
I have no competitors, and I'm not looking to compete. Allow me to
blow your mind and say that I am doing this for the sheer thrill of
creating my own applications for my own personal use that doesn't
involve competitors, those that probably don't design "wierd"
"counterinutitive" software for your PC.
I will attempt to rephrase what I said, in the event
that it may be of use to you in future.*
> > ...counterinutitive software the hell off my PC, and go
> > with the version made by your competitors.
(Ummm..) OK. Given the target group, I was far
too blunt and direct there..
FWIW. My apologies, my comment was uncalled for.
> I have no competitors, and I'm not looking to compete. Allow me to
> blow your mind and say that I am doing this for the sheer thrill of
> creating my own applications for my own personal use that doesn't
> involve competitors, those that probably don't design "wierd"
> "counterinutitive" software for your PC.
* When (later) making applications for 'general users',
always attempt to follow the 'path of least surprise'.
This is the way of going about things, that would be
most obvious to the end user. If you have a GUI where
the task seems to justify breaking away from the
path of least surprise, it is best to
- check that with more experienced GUI developers,
by describing ...
- what end ability you wish to provide to the end user, ..
- your proposed path to achieve that, and ..
- asking if there are better ways to provide that ability
(the answer might be hidden in some class not yet
encountered).
- Even once you have what seems to be an on-screen
solution, sit actual end users in front of it, and check
that they can understand what they see (if they ask
"What does it do?" that is a good indication of 'no'**),
and how it works.
** I mention that specifically because I have had that
reaction to some of my own GUI ideas! Time to dump
that approach and try something entirely new...
> Glad you don't design spellcheckers;
Yes, I make spelling mistakes, but then..
Eye Haight spell chequers. ;-)
Andrew T.
..now a featured staple in Firefox! :)
>
> Andrew T.