3.1.5 seems to have choked off the slow but steady stream of ‘really weird bugs’. Good catch on the threading problems! I wonder how many of the still open bugs could also be put down to that?
Bug [2794703] StackOverFlow using Embellishment level following property
If an Embellishment level following a property is not an integer, it causes
a StackOverflow trying to report the trait name. This was a bug introduced
into 3.1.5 when Bug 2787242 was fixed.
Also modified the error reporting for Embellishment Level following a
property. A value of null for the property no longer reported as an error,
but is interpreted as the First level value so that the initial level is
displayed. Bug fix 2787242 was causing spurious error reports.
(Incidentally, the work I’m doing on editors would also prevent these
problems, unless they were introduced by hand-editing a buildFile, since
the numeric editors do validation as you type. E.g., you can’t get a
number with a decimal point in an IntegerEditor because it won’t let you
type a period.)
Most of the Integer fields in traits are actually input as StringConfigurers since they can contain either an integer OR a Formatted String Expression (e.g. $variable$).
I am in the process of replacing Formatted String Expressions with BeanShellExpressions (aka JavaExpressions), but the problem remains that these fields can contain either a basic type (e.g. Integer) validated at Edit time or an expression that can only be evaluated and validated during play
Generalising this, any field at all could potentially (should?) allow the entry of an Expression instead of a basic validated type.
That’s ok—what’s permissible is determined by the validator you use.
Here’s the Validator interface as I have it right now:
public interface Validator {
public static final int INVALID = -1;
public static final int INTERMEDIATE = 0;
public static final int VALID = 1;
public int validate(String input);
public String fixup(String input);
}
These can be attached to Editors which have text fields. Whenever a change
is made, validate() is called, and will return one of the constants defined
just above it. Valid input is acceptable as-is, and invalid input is clearly
unacceptable. Intermediate input is something which isn’t valid now, but
could be with some editing. (E.g., ‘foo’ is invalid as an integer in base 10.
‘-’ is intermediate because the user could be on his way to typing a negative
number.) The purpose of fixup() is to convert an invalid input into a valid
one (which might not always be possible to do in a sensible way). (For
comparison, this is the same way that Qt does input validation. I found that
it worked pretty well when I used Qt.)
This is what my IntegerValidator implementation looks like right now:
public class IntegerValidator implements Validator {
public int validate(String input) {
// the empty string and a minus sign are intermediate
if (“”.equals(input) || “-”.equals(input)) return INTERMEDIATE;
// everything else which does not parse to an integer is invalid
try {
Integer.parseInt(input);
return VALID;
}
catch (NumberFormatException e) {
return INVALID;
}
}
public String fixup(String input) {
return input;
}
}
For expressions, the validator could feed the expressions to the BeanShell,
and check whether it thinks they’re ok, right?
Sure, but how do you envisage the interaction between an integer and a partial expression within the same field?
The model I am working on at the moment is that BeanShell expressions will be enclosed by braces {} to identify them. I need to do this to be able to distinguish BeanShell expressions from Formatted String expressions that may exist from a module created with an older version of Vassal.
No. I’m saying that you have a BeanShellValidator for fields where you
can type BeanShell expressions, and that would cover both the case where
you type a BeanShell expression which is just an integer and the case
where you type a more complex expression.
The IntegerValidator (with some additional bounds) is still useful for
places where we don’t want the user to type a BeanShell expression, like
for the heap size prefs.
I’ve noticed that we seem to be ahead of the bugs now. I doubt that many
of the remaining reports are related to the threading problems I fixed.
Swing threading problems have a particular signature, namely that you get
an NPE in a Swing method which has no obvious cause. Are any of the open
bugs like this (I haven’t checked recently.)
It would be great if we could close out most of these soon.