🚀 go-pugleaf

"Tor Iver Wilhelmsen" <tor.wilhelmsen@sds.no> wrote in message
news:ubswhpbt3.fsf@sds.no...
> "James Cook" <jimcook.remove.for.spam@iname.com> writes:
>
> > 1. They don't prevent me from clicking on a button, checkbox, or
combobox.
> > In fact, the behavior is pitiful. First the InputVerifier fires and I
get
> > notified of a validation problem in my textfield. Then the mouseclick on
any
> > of the other components gets fired. These components then respond to the
> > mouseclick event! What's up with that? True to form, the focus does not
> > shift from the textfield, but that is small consolation if you just
> > submitted the data, or closed the dialog.
>
> Have the effect of the button click "hang" on the completion of the
> verification. You will have that problem for _all_ event-driven
> systems: If you have inter-dependencies on events, you need to use
> some sort of flags.

But that's the whole purpose of the InputVerifier class. It is perfectly
within the Swing architects realm of possibility to consume any outstanding
mouse events *before* focus shifts from a JComponent with an InputVerifier.
What purpose does the class serve otherwise. it is rendered effectively
useless.

> > 2. How does one assign an InputVerifier to an *non-editable* JComboBox?
Now
> > one may argue that there is not a need to make sure that a combobox
> > selection needs to be verified, but there are circumstances where two or
> > more combos need their selections to jive.
>
> Why do you need to use that event? Why not evaluate on the
> ChangeEvent?
For consistency. For focus control.

jim