Numeric characters truncated during editing

Hi,
Sorry if this has been posted before, but I’m making a large number of numeric edits (i.e. at-start coordinates) to a module I’m working on, and I’ve discovered that the edits will frequently experience one of two problems:
(a) The edit will not be applied at all; that is, the value will remain as it was before I opened the edit dialog, or
(b) The edit will be applied with the last character truncated.
I have noticed this behavior in two places:
(1) Editing the X- and Y-coordinates of an at-start stack
(2) Editing the value of a marker within a piece; this is always numeric in my module.
So far as I can recall, this has only happened with numeric edits, though perhaps I’ve seen it in alpha properties before and just attributed it to clumsy fingers (which is what I thought for a long time with the numbers, even though I am a very careful typist). This also seems to occur more frequently the larger my module grows; currently it has about 300 at-start stacks on the main map, and I’ve gotten the truncation on 6 of my last 50 edits, where I probably had this problem no more than twice in the first 200 edits. Finally, once a particular property experiences a single truncation, it is highly likely that I will have to reattempt that particular edit multiple times, perhaps as many as 5 times.
Of course the module is not finished, but I can provide a link if necessary. Using Vassal 3.1.17 and JRE 1.6.0_29.

Cheers,
Seth

After further experimentation, I do not believe this bug is related to the size of the module - I think the reason I started noticing it more over time is due to my own changing interaction with the editor. That is, fields that have focus when ‘OK’ is pressed on the relevant dialog do not seem to ever be truncated. In the process of performing many similar edits, I usually switch to a keyboard-only input pattern, i.e tabbing to the ‘OK’ button, which takes the focus away from all input fields - resulting in a much higher number of truncations.

Thus spake irishwulf:

After further experimentation, I do not believe this bug is related to
the size of the module - I think the reason I started noticing it more
over time is due to my own changing interaction with the editor. That
is, fields that have focus when ‘OK’ is pressed on the relevant dialog
do not seem to ever be truncated. In the process of performing many
similar edits, I usually switch to a keyboard-only input pattern, i.e
tabbing to the ‘OK’ button, which takes the focus away from all input
fields - resulting in a much higher number of truncations.

Put a bug report into the tracker for this to ensure that someone looks
at it. We’re in the usual holiday slump right now, but in a week or so
my guess is that we developers will be active again.


J.

Thank you, Joel, committed as 4184.

Cheers,
Seth

Thus spake irishwulf:

After further experimentation, I do not believe this bug is related to
the size of the module - I think the reason I started noticing it more
over time is due to my own changing interaction with the editor. That
is, fields that have focus when ‘OK’ is pressed on the relevant dialog
do not seem to ever be truncated. In the process of performing many
similar edits, I usually switch to a keyboard-only input pattern, i.e
tabbing to the ‘OK’ button, which takes the focus away from all input
fields - resulting in a much higher number of truncations.

I’ve looked at this and doesn’t reproduce for me. It can’t be the focus as the system is internally changing its value every time you type a key, so if you type “123” it sets the integer internally to 1 then 12 and then 123. Once you hit OK these values are copied to the appropriate place.

George,
Couldn’t it still be the focus? I have observed this behavior on component name properties as well, in which case the name as reflected in the configure tree list is truncated. More accurately, my edit is truncated, as though some buffer of my keystrokes is flushed prematurely. Say I change ‘PlayerWindow1’ to ‘PlayerMap1’ by setting my cursor to the left of the 1, backspacing, then typing ‘Map’; I will very rarely get the following in the main editor window:
PlayerMa1
…but ‘PlayerMap1’ in the dialog in which I’m entering text. I can’t remember whether I changed the focus away from the name field before observing the ‘PlayerMa1’, but the dialog was certainly still open. I can’t think off the top of my head how the focus can be a factor, unless the buffer is cleared differently on exiting the dialog, but with continued experimentation I am now 99% certain that retaining focus when clicking ‘OK’ correctly applies the changes.
In any case, the behavior is inconsistent (which is one of the most infuriating things about it) - I was not able to reproduce it just now in a fresh module using roughly 100 purely at-start stack coordinate edits. Perhaps it starts appearing after a very high number of consecutive edits; I may only start seeing it after after several days of edits to a module. I’ll try to provide a better sequence for reproducing the behavior as I continue to observe it.

I would think this sounds like some sort of Java redisplay bug. I can’t
imagine what Vassal would do that would trigger that behavior.

Only, the property is actually saved as the truncated value. For example, if the property is an X coordinate of an at-start stack, the stack will display at, say, X=63, instead of X=634.

-Seth

Thing is, if you save and reopen your number will display correctly right?
Other things get truncated in the editor also, the reason unclear but I’m
inclined to think this is a java display issue as well like Tom thinks
seeing as everything is built with swing

-----Original Message-----
From: messages-bounces@vassalengine.org
[mailto:messages-bounces@vassalengine.org] On Behalf Of irishwulf
Sent: Wednesday, January 25, 2012 7:13 PM
To: messages@vassalengine.org
Subject: [messages] [Technical Support & Bugs] Re: Numeric characters
truncated during editing

Only, the property is actually saved as the truncated value. For example,
if the property is an X coordinate of an at-start stack, the stack will
display at, say, X=63, instead of X=634.

-Seth


Read this topic online here:
https://forum.vassalengine.org/t/numeric-characters-truncated-during-editing/4539/8

I think I have this reproducible, and I think I know why it happens. StringConfigurer fires a propertychangeevent on key release, which then updates propertychangelisteners, (I think) including the actual source attribute. However, when I am making a lot of edits I am often typing very fast - so say I am changing a marker ‘Cost_1’ with value ‘6’ to marker ‘Cost_2’ with value ‘5’, I will backspace the ‘1’, type ‘2’, hit TAB immediately, such that the key release is (I imagine) fired for the TAB, and not the 2, and change the marker value. Clicking ‘OK’ probably only helps because it forces me to pause long enough in the field for the key release event to fire appropriately and update the propertychangelisteners. So, to reproduce:
(1) Create a marker trait
(2) Start to type for the name of the marker ‘MyProp_y’. As quickly as possible after hitting the ‘y’, tab to the next field.
(3) Reenter the marker, observe, hopefully, ‘MyProp_’.

Supposedly the correct design for listening to changes to JTextFields is by using either TextEvents or DocumentEvents, not KeyEvents. Sorry it took so long to come up with a reproducible pattern, but I hope that helps.

Cheers,
Seth

Thus spake irishwulf:

I think I have this reproducible, and I think I know why it happens.
StringConfigurer fires a propertychangeevent on key release, which then
updates propertychangelisteners, (I think) including the actual source
attribute. However, when I am making a lot of edits I am often typing
very fast - so say I am changing a marker ‘Cost_1’ with value ‘6’ to
marker ‘Cost_2’ with value ‘5’, I will backspace the ‘1’, type ‘2’, hit
TAB immediately, such that the key release is (I imagine) fired for
the TAB, and not the 2, and change the marker value. Clicking ‘OK’
probably only helps because it forces me to pause long enough in the
field for the key release event to fire appropriately and update the
propertychangelisteners. So, to reproduce:
(1) Create a marker trait
(2) Start to type for the name of the marker ‘MyProp_y’. As quickly as
possible after hitting the ‘y’, tab to the next field.
(3) Reenter the marker, observe, hopefully, ‘MyProp_’.

Supposedly the correct design for listening to changes to JTextFields is
by using either TextEvents or DocumentEvents, not KeyEvents. Sorry it
took so long to come up with a reproducible pattern, but I hope that
helps.

I switched StringConfigurer to use DocumentEvents in the svn8054 build:

vassalengine.org/~uckelman/builds/

  1. Does this resolve the problem for you?
  2. Does this break anything else? Spend some time checking places where
    there are text fields.


J.