handling focusLost Events

Re: handling focusLost Events

Nuggy wrote:
[color=blue]
> Ok, I'm ready to toss this thing across the room. Here's what I'm
> trying to accomplish, greatly simplified:
>
> I have a screen with several text fields. I want to validate the
> entry in each text field when the user tabs out of it to the next one
> (some fields are required). If they enter an invalid entry or leave
> it blank, I want to display a pop-up in the form of a
> JOptionPane.sho wMessageDialog to inform them of the problem, then
> reset focus to the invalid field.
>
> Here's the problem: fields a, b, and c are all validated this way,
> and are sequential in the focus order. In a new screen, if the user
> enters an invalid value into field a, field b briefly gets the focus
> from the tab key, and in the course of popping up the box and
> resetting focus to field a, field b loses this brief focus, gets
> validated because of this, and I end up with two and sometimes three
> pop-up boxes that I don't want. I am using isTemporary(); without it
> I end up in an infinite loop of popups.[/color]

Classic deadlock error. Create a flag that prevents this. If you see the
need to create a validation dialog, first set a "busy" flag, then show the
dialog. In your event handler code, first test the flag, if it is set, do
nothing.

Once the dialog is dismissed and the focus has been reset to the previous
field, then clear the flag. This allows the event handlers to function
normally again.
[color=blue]
> I've spent two days trying ideas and I'm still plagued by these
> "phantom" popups.[/color]

All you have to do is think it through. Your event handlers think any
focus-lost event is equal to any other. But they are not the same -- some
are initiated by the user, and some by your dialog.

--
Paul Lutus

Re: handling focusLost Events

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nuggy wrote:
[color=blue]
> I also want to NOT perform the focus lost validation if the user
> clicks a "clear" button that clears out all the data on the screen.
> It won't let the user do this because when you click the button it
> validates the field you were in, and if it's not valid you get the
> dialog popup.[/color]

Hello,
I think this part is probably the hardest. Try to consider people
using the keyboard to navigate your program: when they want to get to
the clear button, they have to Tab through all the other fields to
get there. This means they have to validate, just for the user to get
to the clear button. Personally, I would consider just putting a
little marker, which should be fairly non-intrusive, beside each
field. If it invalidates, put a short message (maybe written in red
text or something) that says so. Finally, as long as one or more
fields are invalid, disable the submission button! The user can't go
any further until the fields are valid, and they know which ones are
valid and which aren't. I think this is a much friendlier way of
accomplishing the same result, especially to keyboard users.

If you REALLY want to do this, though, what you'd need to investigate
is the use of FocusEvent.getO ppositeComponen t(). It'll tell you what
component focus is moving to, in the case of a lost focus event. For
your mouse users, that'll allow them to click the Clear button. For
your keyboard users, well, hopefully the first element in the window
is the first field of the form, and the last element in the window is
the Clear button. That way, assuming they're smart enough, they
should be able to Shift+Tab backwards through form fields that are
already valid, until they wrap around backwards and get to the Clear
button.

- --
Chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/mbTfwxczzJRavJY RAmZgAKCafWUXTQ yQ7xeN/MVSdKM+qbiuswCe ISfr
OhiYvqJ+eHo5bsK bYvl4muE=
=QWpQ
-----END PGP SIGNATURE-----

Re: handling focusLost Events

You could also try using a InputVerifier and its .shouldYieldFoc us()
method to block the focusLost from ever being called when the data is
invalid.

Bill Dennis