Create account / Log in

Numeric characters truncated during editing

Issues with the Vassal engine.

Moderators: uckelman, Tim M

Numeric characters truncated during editing

Postby irishwulf » December 28th, 2011, 2:26 am

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
irishwulf
 
Posts: 243
Joined: December 17th, 2011, 4:29 am

Re: Numeric characters truncated during editing

Postby irishwulf » December 31st, 2011, 9:45 am

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.
irishwulf
 
Posts: 243
Joined: December 17th, 2011, 4:29 am

Re: [messages] [Technical Support & Bugs] Re: Numeric charac

Postby uckelman » December 31st, 2011, 3:22 pm

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.
User avatar
uckelman
Site Admin
 
Posts: 8797
Joined: December 10th, 2007, 9:48 am
Location: Durham, England

Re: Numeric characters truncated during editing

Postby irishwulf » December 31st, 2011, 7:53 pm

Thank you, Joel, committed as 4184.

Cheers,
Seth
irishwulf
 
Posts: 243
Joined: December 17th, 2011, 4:29 am

Re: Numeric characters truncated during editing

Postby george973 » January 25th, 2012, 7:41 pm

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.
george973
 
Posts: 68
Joined: May 19th, 2008, 2:15 pm
Location: Ipswich, UK

Re: Numeric characters truncated during editing

Postby irishwulf » January 25th, 2012, 10:31 pm

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.
irishwulf
 
Posts: 243
Joined: December 17th, 2011, 4:29 am

Re: [messages] [Technical Support & Bugs] Re: Numeric charac

Postby tar » January 26th, 2012, 12:56 am

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.
User avatar
tar
 
Posts: 776
Joined: January 2nd, 2008, 6:53 pm
Location: Los Angeles area

Re: Numeric characters truncated during editing

Postby irishwulf » January 26th, 2012, 1:12 am

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
irishwulf
 
Posts: 243
Joined: December 17th, 2011, 4:29 am

Re: [messages] [Technical Support & Bugs] Re: Numeric charac

Postby Tim M » January 26th, 2012, 2:44 am

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:
viewtopic.php?p=30076#p30076
Tim,
Vassal Uber Geek/Guru

Problems? post your OS, Physical Mem, version of Vassal and Java plus the Module in question.
No developer can help with out that info, thx!
User avatar
Tim M
 
Posts: 1812
Joined: December 8th, 2007, 12:22 pm
Location: Earth

Re: Numeric characters truncated during editing

Postby irishwulf » January 27th, 2012, 1:59 pm

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
irishwulf
 
Posts: 243
Joined: December 17th, 2011, 4:29 am

Re: [messages] [Technical Support & Bugs] Re: Numeric charac

Postby uckelman » February 1st, 2012, 6:04 am

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:

http://www.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.
User avatar
uckelman
Site Admin
 
Posts: 8797
Joined: December 10th, 2007, 9:48 am
Location: Durham, England


Return to Technical Support & Bugs

Who is online

Users browsing this forum: No registered users and 3 guests