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

PSPNum Persistence

The following PSPNum properties are persistent (serialized):

DigitsBeforeDP Integer. Number of digits before decimal place.
DigitsAfterDP Integer. Number of digits after decimal place.
Value String. Numeric value as unformatted string.
Mask String. Edit mask to format Text from Value.
Round Boolean. Whether arithmetic rounding applies.
OverflowKey Integer. Treatment for overflow for keying.
OverflowCode Integer. Treatment for overflow for operations in code.
ActiveBackColor Color. The background color for when the PSPNum has the input focus.
TextAlign Integer. Whether Text is left/centre/right aligned.

Note that neither of the Text or TextRefresh properties are persistent. This is because PSPNum always refreshes the Text (from the persistent Value using the persistent Mask) when the PSPNum is initialised. If you want to set TextRefresh to false, you can only do this after the PSPNum has been initialised.

In addition to properties specific to PSPNum, other properties inherited from parent objects (TextField->TextComponent->Component->Object) are persistent e.g. Fonts, Colors and whether the component is editable.

Note that although the TextAlign property is serialized, the Text (numeric value) may only display left-aligned immediately after the PSPNum is deserialized. This is due to the natural sequence of deserialization of PSPNum and its parent TextField. When the PSPNum next gains the input focus, the correct alignment should be set. If you want to force correct alignment immediately after deserialization, you may want to try a line of code such as Num.setTextAlign(Num.getTextAlign()); immediately after all deserialization has completed. Underlying this problem is the fact that the TextField object unfortunately has no natural text alignment setting, so PSPNum is forced to insert leading blanks to give the impression of alignment.

Apart from the one issue above, our testing indicates that the default persistence mechanism provided by the Java Serializable interface is satisfactory. So far we have found no reason to implement the more sophisticated Externalizable interface for PSPNum. It is highly unlikely that we will do anything (e.g. delete PSPNum properties) that will break the default serialization mechanism in future versions of PSPNum.

We welcome any comments/suggestions from users in this area.