Bug #8365
FILL-IN: editing character issues
0%
History
#1 Updated by Vladimir Tsichevski about 2 months ago
This task is dedicated to issues related to FILL-IN with character format.
#2 Updated by Vladimir Tsichevski about 2 months ago
If the SCREEN-VALUE of the FILL-IN is set to unknown, the screen value is replaced by ? as expected, but this question mark cannot be erased neither with Delete, Backspace nor with delete selection operation.
If the user enters any valid input character though, the question mark is replaced by the entered character as expected.
#3 Updated by Vladimir Tsichevski about 2 months ago
If the user enters the ? in the first position, the screen value is replaced by ? as expected.
If the user moves the cursor right the the Right-Arrow, then presses Delete, the ? character is deleted. The Delete key in this situation behaves in FWD similar to Backspace
In OE no deletion happens in this situation.
#5 Updated by Vladimir Tsichevski about 2 months ago
In character mode, the Home and End keys should move the focus the the first and the last item in the focused widget ring.
In FWD, these keys work as in GUI mode: they move cursor in the focused FILL-IN to the first and last positions.
So, this issue is not limited by the character editing fill-ins.
#6 Updated by Vladimir Tsichevski about 2 months ago
Vladimir Tsichevski wrote:
In character mode, the
HomeandEndkeys should move the focus the the first and the last item in the focused widget ring.In FWD, these keys work as in GUI mode: they move cursor in the focused
FILL-INto the first and last positions.So, this issue is not limited by the character editing fill-ins.
This issue is probably affected by the fact I was comparing the FWD Swing ChUI mode with OE on Windows. Probably, OE character mode on Linux behaves differently.
#7 Updated by Vladimir Tsichevski about 2 months ago
- File 8365-7-OE.png added
- File 8365-7-FWD.png added
OE displays the TAB character in character FILL-IN, but FWD does not.
The test program:
DEFINE VARIABLE fillIn AS CHARACTER NO-UNDO VIEW-AS FILL-IN. DEFINE FRAME mainFrame fillIn WITH SIZE 75 BY 20 AT ROW 3 COL 5. fillIn:SCREEN-VALUE = "a~tb". ASSIGN fillIn. MESSAGE fillIn LENGTH(fillIn). MESSAGE fillIn:SCREEN-VALUE LENGTH(fillIn:SCREEN-VALUE). ENABLE ALL WITH FRAME mainFrame. WAIT-FOR GO OF FRAME mainFrame.
The screen in OE:
the same screen in FWD:
#8 Updated by Vladimir Tsichevski about 2 months ago
Another issue: the trailing whithespace characters other than SPACE must not be trimmed in fillIn:SCREEN-VALUE.
In FWD trailing all whitespace characters are trimmed.
#9 Updated by Vladimir Tsichevski about 2 months ago
Vladimir Tsichevski wrote:
Another issue: the trailing whithespace characters other than
SPACEmust not be trimmed infillIn:SCREEN-VALUE.
In FWD trailing all whitespace characters are trimmed.
This happens here (GenericWidget):
character getScreenValue(boolean initialized, BaseDataType bdt, String fmt, boolean ignoreFormat)
{
if (!initialized)
{
return new character("");
}
if (bdt.isUnknown())
{
return bdt.getClass().isAssignableFrom(date.class) ? new character("") : new character();
}
// format the value
// TODO: is this always the same as the way the display would format it?
// some widgets like selection-list can have screen value outside the format in multiple
// selection case so we need the option to get this value too
String formatted = ignoreFormat ? bdt.toStringMessage() : bdt.toString(fmt);
... ^^^^^^^^^^^^^^^^^
When the value is formatted, all kinds of trailing whitespaces are replaces by spaces.
I do not know whether it is the formatting we should fix, or we should not use formatting here at all.