> While you seem spot on in your analysis that the focusLost handling of
> the JFormattedField is probably the culprit, I'm afraid I still don't
> quite understand the behaviour. (On JDK 1.4.2_05 - Linux, you may be
> testing on another version, so your observation may be different)
neither do I - after re-visiting the problem :-)
> For instance, if I put the cell into editing mode by double-clicking,
> select the contents and click on the JButton, Cut doesn't seem to work.
> If on the other hand, I enter some keystrokes into the editor and then
> do the same thing, it seems to suddenly perform the Cut properly.
Hmm, then the behaviour seems to be really undeterministic - currently
the cut on the first column works the very first time after starting the
test app (unchanged except for a slightly saner model that does not
insist on the famous 42).
> [The
> source code shows an invokeLater call in the focus lost handler that
> delays the action to the next EDT cycle if the contents have changed :
> may be that causes this difference]
interestingly that handler seems to (being cautious ;) not always be
called ...
> As for why Mike "believing" :-) about the table still remaining in
> editing mode, I would have probably come to the same conclusion, because
> it "looks" so. The string is still left justified in the field (the
> renderer shows it right justified) - Only the selection seems to vanish.
yeah - I was blind.
> Calling setRequestFocusEnabled(false) on the JButton seems to cure the
> problem altogether - (which again points to the focus handling being the
> probable cause of the problem).
I'm pretty sure it's "somehow" related to focus - but can't nail it
down.
> Also I don't quite understand why the editing should get terminated with
> the JFTF even when the "terminateOnFocusLost" property of the JTable is
> FALSE. The JFTF does call its own commitEdit directly - but I couldn't
> quite spot it firing any ActionEvents. May be I didn't read the source
> too cosely.
again, I stand corrected (no actionEvents fired) - wasn't my day. Sorry
for the confusion I caused.
Jeanette
Babu Kalakrishnan - 29 Nov 2004 15:52 GMT
>>While you seem spot on in your analysis that the focusLost handling of
>>the JFormattedField is probably the culprit, I'm afraid I still don't
>>quite understand the behaviour. (On JDK 1.4.2_05 - Linux, you may be
>>testing on another version, so your observation may be different)
>
> neither do I - after re-visiting the problem :-)
Going into the realm of speculation (too lazy and too little spare time
to go and trace it down), I get a feeling it has something to do with a
code segment which says :
if (isEdited() && e.getID() == FocusEvent.FOCUS_LOST) {
// My comments here :
// Do something
// Also delays the handler if some events
// are pending to be processed
}
else if (!isEdited()) {
// reformat
setValue(getValue(), true);
}
I wonder if that last setValue which is called when isEdited is false
(wonder why the call at all : why is a reformat reqd if it wasn't edited
?? ) causes the field to deselect the contents (as was my observation).
If there is no selection, obviously there's nothing to cut.
BK
VisionSet - 30 Nov 2004 10:56 GMT
> Going into the realm of speculation (too lazy and too little spare time
> to go and trace it down), I get a feeling it has something to do with a
[quoted text clipped - 15 lines]
> ?? ) causes the field to deselect the contents (as was my observation).
> If there is no selection, obviously there's nothing to cut.
Thanks all, the setRequestFocusEnabled solution works fine for me.
A setValue is called explicitly in my own code in the ProblemEditor class.
Removing that line solves the uncuttable problem.
--
Mike W