Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / GUI / February 2007

Tip: Looking for answers? Try searching our database.

JFormattedTextField commit listener?

Thread view: 
Eric Smith - 14 Feb 2007 09:53 GMT
Is there some way for an object to get notified when
a JFormattedTextField commits?  I tried doing a
getDocument() and setting a DocumentListener,
but that gets called during intermediate
editing steps, and there's no obvious way
it can tell when the edit is committed.

Thanks,
Eric
Eric Smith - 14 Feb 2007 10:18 GMT
I asked:
> Is there some way for an object to get notified when
> a JFormattedTextField commits?

I've got part of the answer.  The JFormattedTextField apparently
changes a "value" attribute when the field commits.  I can't find
anywhere that this is documented; I found it by looking at the
source code for the GNU Classpath implementation of JFormattedTextField,
and experimentally determined that the Sun implementation does it
as well.  However, the getOldValue() and getNewValue() methods of
the PropertyChangeEvent both return null, which seems broken.

The bigger problem is that when using a MaskFormatter, the field
doesn't seem to commit when return is pressed (and the contents are valid),
though it does commit if it loses the focus because I click in a
different field.  Ugh.  Any way to force it to commit on the return
key?

Thanks,
Eric
Rogan Dawes - 14 Feb 2007 15:54 GMT
> I asked:
>> Is there some way for an object to get notified when
[quoted text clipped - 16 lines]
> Thanks,
> Eric

Use an ActionListener. But also see my response to your other mail.

Rogan
Eric Smith - 14 Feb 2007 22:49 GMT
> Use an ActionListener. But also see my response to your other mail.

Thanks!  For some reason that wasn't obvious to me when studying
the docs on the JFormattedTextField and its superclasses.
Eric Smith - 14 Feb 2007 23:35 GMT
I asked:
> Is there some way for an object to get notified when
> a JFormattedTextField commits?
And later I wrote:
> The JFormattedTextField apparently
> changes a "value" attribute when the field commits.
[...]
> when using a MaskFormatter, the field
> doesn't seem to commit when return is pressed (and the contents are valid),
> though it does commit if it loses the focus because I click in a
> different field.

> Use an ActionListener. But also see my response to your other mail.

Interesting.  The ActionListener fires if a return is pressed, but
not if a commit occurs because the focus is lost.  So if I use this
approach, I have to have both an ActionListener and a
PropertyChangeListener.

It seems bizarre that there's no easy way to get notification of
commits of a JFormattedTextField.  I think I'll take your other
advice and go back to using a JTable.

I think some of my complaints about using the JTable are solved if
instead of making my Memory class implement the AbstractTableModel, I
use a separate object for that, as you did in your HexForm class.

Thanks,
Eric
Rogan Dawes - 16 Feb 2007 13:16 GMT
> I asked:
>> Is there some way for an object to get notified when
[quoted text clipped - 14 lines]
> approach, I have to have both an ActionListener and a
> PropertyChangeListener.

You might also use a FocusListener to trigger the action. See
JTextField.postActionEvent()

The FocusListener would trigger the event whenever focus is lost.

> It seems bizarre that there's no easy way to get notification of
> commits of a JFormattedTextField.  I think I'll take your other
> advice and go back to using a JTable.

The question is, what do you define as a commit? A commit suggests that
there is some definite action that trigger the commit. That is typically
something like "pressing enter", etc. And that is exactly what is
happening here.

Otherwise you are talking about a keypress, and that is easy to monitor
with a DocumentListener as well.

> I think some of my complaints about using the JTable are solved if
> instead of making my Memory class implement the AbstractTableModel, I
> use a separate object for that, as you did in your HexForm class.
>
> Thanks,
> Eric

You did say that you didn't want your domain object to know about your
GUI implementation, so making Memory implement AbstractTableModel is the
wrong solution.

If you have your Memory class firing MemoryEvent's, create a
MemoryTableModel that extends AbstractTableModel, and implements
MemoryEventListener. This adapter class will simply translate
MemoryEvent to TableModelEvent in one direction, and accesses to table
cells into memory positions in the other direction.

This is quite a common pattern, in fact. See
http://en.wikipedia.org/wiki/Adapter_pattern

Rogan
Eric Smith - 17 Feb 2007 12:46 GMT
> The question is, what do you define as a commit? A commit suggests
> that there is some definite action that trigger the commit. That is
> typically something like "pressing enter", etc. And that is exactly
> what is happening here.

JFormattedTextField defines what a commit is, and allows the user
to specify a few choices about how and when to commit.  I want to
be notified of exactly when JFormattedTextField does a commit,
and at no other times.

> Otherwise you are talking about a keypress, and that is easy to
> monitor with a DocumentListener as well.

I specifically do NOT want to be notified of all keypresses, since
most of them do not trigger a commit.  I mentioned before that
I tried using a DocumentListener and didn't get what I want.

It seems bizarre that whoever developed JFormattedTextField at
Sun went to all the trouble to implement and document various
commit behaviors, but not provide an explicit way to listen
for a commit.
Rogan Dawes - 17 Feb 2007 14:48 GMT
>> The question is, what do you define as a commit? A commit suggests
>> that there is some definite action that trigger the commit. That is
[quoted text clipped - 5 lines]
> be notified of exactly when JFormattedTextField does a commit,
> and at no other times.

Oops, sorry. I actually haven't used J*Formatted*TextField before.

I agree that it doesn't seem to be possible to be notified of a commit,
other than by using a PropertyChangeListener, as you described
previously. For what it is worth, I tried it myself, and did get the
correct new and old values from the event.

>> Otherwise you are talking about a keypress, and that is easy to
>> monitor with a DocumentListener as well.
[quoted text clipped - 7 lines]
> commit behaviors, but not provide an explicit way to listen
> for a commit.

Yes, it does seem odd that you can't do this easily.

The "best" way (using best loosely), seems to be to subclass
JFormattedTextField, override commitEdit, and take whatever action you
want after you have called super().commitEdit();

public class FormattedFieldTest {

    public static void main(String[] args) {
        JFrame frame = new JFrame();
        final JFormattedTextField tf = new JFormattedTextField() {
            public void commitEdit() throws ParseException {
                super.commitEdit();
                System.out.println("New value is : " + getValue());
            }
        };
        tf.setValue(new Integer(100));
        tf.setMinimumSize(new Dimension(300, 40));
        frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        frame.getContentPane().setLayout(new FlowLayout());
        frame.getContentPane().add(tf);
        frame.getContentPane().add(new JButton("A button"));
        frame.pack();
        frame.setVisible(true);
    }

}

The button is added simply so that "focusLost" behaviour can be observed.

Hope this helps.

Rogan
Eric Smith - 19 Feb 2007 09:09 GMT
> The "best" way (using best loosely), seems to be to subclass
> JFormattedTextField, override commitEdit, and take whatever action you
> want after you have called super().commitEdit();

The docs say that you can use commitEdit() to force a commit:

   Forces the current value to be taken from the AbstractFormatter and set
   as the current value.

It wasn't clear to me from that description that commits generated by the
class itself invoke commitEdit(); that would be a logical way to implement
it, but it's also possible that commitEdit() is a different code path
that calls internal methods that have the same behavior as an
automatic commit.

I'll give it a try, but since it isn't documented to work that way, I'd
be reluctant to use it in my real code since it could change in future
SDK releases.

Thanks,
Eric
Ian Wilson - 15 Feb 2007 10:01 GMT
> Is there some way for an object to get notified when
> a JFormattedTextField commits?  I tried doing a
> getDocument() and setting a DocumentListener,
> but that gets called during intermediate
> editing steps, and there's no obvious way
> it can tell when the edit is committed.

Doesn't the verify() method of an InputVerifier get called when the edit
is committed?
Eric Smith - 15 Feb 2007 22:41 GMT
> Doesn't the verify() method of an InputVerifier get called when the
> edit is committed?

I'll give that a try.  Wouldn't MaskFormatter already be supplying its
own InputVerifier?  So I'd have to write a wrapper for it?

Thanks,
Eric


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.