Want more information ?. Try the Web Home Page for this document.

PSPNum versus JCurrencyTextField (from KL Group)

The table below summarises differences between our PSPNum JavaBean and the JCurrencyTextField JavaBean from KL Group. This is based on a comparison of version 3.8 of PSPNum and their version 'JClass Field 3.0.0 for JDK 1.1'. We hope that the comparison is unbiased and welcome criticism if anyone believes otherwise.

Feature

PSPNum

JCurrencyTextField

Our Comment
Internal numeric value: Our PSPDec class. Floating-point (Double). You might argue that floating-point is 'accurate enough' for most uses e.g a high percentage (less than 100%) of the time. But our decimal numeric values are unequivocally valid - 100% always. We believe floating-point is untenable. See our comparison of PSPDec versus floating-point.
Size of Decimal Number: Specified directly via DigitsBeforeDP and DigitsAfterDP properties. Specified implicitly via the EditPattern, min and max properties. A different view of the world. KL's masking technique suggests a decimal numeric solution imposed on a generic text value. Our solution emphasises that the number of digits either side of the decimal place is critical to the numeric value (particularly in a multi-currency application) and is a 'Value' issue not a 'Mask' issue.
Events triggered (other than standard ones for GUI component): PropertyChange events for major properties such as Value, Mask, DigitsBeforeDP and DigitsAfterDP. fieldvalueChanged events for change of Value. No events for change of Mask (DisplayPattern or EditPattern) fields. Certain major properties control the decimal numeric value of the bean i.e. the Value/fieldValue itself and related properties. We believe changes to any of these should be communicated by events.
Bindable properties: Yes. Currently only 6 basic properties, none of which are 'major' properties relating to numeric value. However these numeric properties are dealt with via PropertyChange events, which we view as more flexible. No. It is debatable how property values can best be communicated to/from other components. Our view is that 'simple' properties such as fonts and colors should be bindable, whereas more 'complex' properties that are critical for each Bean should be monitored by events.
Customizer Class: Yes. No. Customizers provide the best way of editing related properties. All aspects of property editing/display can be controlled instead of via a poorly sequenced list of properties.
Formatted Display of Value: Whenever value changes e.g. after every keystroke. When control loses focus. PSPNum always shows the fully formatted value - there is no distinction between 'edit' and 'display' modes like KL's control.
Digits after decimal place: Control always shows all decimal digits (set by DigitsAfterDP property). You can not key more than this number of digits, which scroll right without rounding. Control drops trailing decimal zeroes when it gains focus (edit mode) and restores them when it loses focus (display mode). You can key any number of decimal digits, which are rounded when the control loses focus. We believe our approach is better. For most monetary input (2 decimal places), users want to see and key always two decimal digits - no more, no less. We believe rounding applies to arithmetic operations only, not to keying.
Arithmetic operations and rounding: Supports a range of simple arithmetic operations for the underlying BigDecimal value. Rounding controlled by boolean property. No built-in arithmetic operations. No property to control rounding (always ON). With KLs control, you have to perform arithmetic operations outside of the control - where you then face the precision and rounding issues associated with floating-point.
Input keying mode: Insert only. Insert or Overstrike. We would introduce Overstrike if requested to do so. Our users tend to highlight and delete entire contents before entering completely new values.
Show/hide caret position: No property for this. Caret always visible when control has focus. showCursorPosition controls visibility of caret when control has focus. KL's approach may be useful if the value is not Editable. Otherwise we tend to believe the caret should always be visible.
Valid/Invalid numeric values: No real distinction. Active distinction via 'state' property. Invalid state (tested when control loses focus) alerts user via change of colors and beep. The 'invalidPolicy' property determines how the control responds to an invalid state. KL's control provides many more options in this area. Our users must monitor focusLost events outside of PSPNum to determine state and how the control responds to invalid values. This is more generic, although undoubtedly more work to implement. PSPNum users can also detect invalid values before focusLost via our propertyChanged events.
Maximum/minimum numeric values: No properties to control these values. Specifically set via 'max' and 'min' properties. KL's approach is tied to their definition of state. For example, an invalid state if value is less than minimum. PSPNum users have to program for this in same way as above.
Caret positioning when focus gained: Three options (under user control) for caret position: 1) same as when focus lost, 2) before decimal place, 3) before first numeric digit. Always to end of displayed value. PSPNum offers many more options for caret positioning. In our experience this is a highly subjective area - users have quite different opinions about what is 'obvious'. We believe we cover the most popular options better.
Other display when focus gained: ActiveBackColor property. HighlightColor and HighlightThickness properties. Two different approaches to highlighting the control if it is the 'active' one i.e. has the input focus. KL's approach is perhaps more sophisticated.

We respect completely KL's commitment to Java and the large number of JavaBeans they have developed. Nevertheless we believe PSPNum is, on balance, better at what it does than JCurrencyTextField. In particular we believe that PSPNum is better at core processing of decimal numeric values and intuitive modeless editing of displayed numeric values.