> Use an ActionListener. But also see my response to your other mail.
> 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