Bug?: Changing the Text Input Box after inputting text
I created a text input box with {{input Id=QUESTION_1 | type=text | lines=4 | prompt=“Type”}} and input:-
1. line 1
2. line 2
3. line 3
4. line 4
5. line 5
then I recompiled with {{input Id=QUESTION_1 | type=text | width=4 | prompt=“Type”}}
The input was still available and I can scroll vertically between the 5 lines. I can't insert a new line, but can generate new "lines" from the blank 6th line onward as the text wraps. If I delete all the text, the new input still wraps. Yet earlier, the text had overflowed without wrapping, requiring horizontal scrolling.
I expected that the original input would be deleted if I recompiled the same Id with different parameters. I can see some advantage in retaining the input, but the outcomes were unpredictable. So how was it designed to work?
Dave
===
Windows 11 & Android 13
Comments
-
Dave Hooton said:
I expected that the original input would be deleted if I recompiled the same Id with different parameters. I can see some advantage in retaining the input, but the outcomes were unpredictable.
@Logos: I strongly support Dave's remark (change in emphasis by me) and encourage you to not discard input text upon recompile of the PB.
Mick
Have joy in the Lord!
0 -
The intent is for input elements in Personal Books to work the same as they do in Logos Editions.
We don't want users to lose data when a Logos Edition is updated, and the same applies to Personal Books.
0 -
Toby Steele said:
We don't want users to lose data when a Logos Edition is updated, and the same applies to Personal Books.
[Y] Thank you Toby and Team Logos.
0 -
Toby Steele said:
We don't want users to lose data when a Logos Edition is updated, and the same applies to Personal Books.
Thanks Toby
Is a width defined box supposed to handle text overflow without wrapping (requiring horizontal scrolling) or with wrapping?
Dave
===Windows 11 & Android 13
0 -
Dave Hooton said:
I can't insert a new line, but can generate new "lines" from the blank 6th line onward as the text wraps.
This seems logical to me and consistent with my observations. A width-defined box is intended for minimal input. Explicit newline or carriage returns shouldn't be allowed as input when the box is in this mode.
Dave Hooton said:Yet earlier, the text had overflowed without wrapping, requiring horizontal scrolling.
I'm unable to replicate any kind of horizontal scroll behavior in a width-defined box. Can you take a screen cast with Jing (or other screencast tool) and post a link?
Dave Hooton said:Is a width defined box supposed to handle text overflow without wrapping (requiring horizontal scrolling) or with wrapping?
Not sure what the intention is; I'll check.
0 -
Toby Steele said:
I'm unable to replicate any kind of horizontal scroll behavior in a width-defined box. Can you take a screen cast with Jing (or other screencast tool) and post a link?
I thought that happened initially, so I'll await your response about the intention.
Dave
===Windows 11 & Android 13
0 -
What is the intended behavior a width-defined box?
Dave
===Windows 11 & Android 13
0 -
Dave Hooton said:
What is the intended behavior a width-defined box?
Width-defined boxes are intended to scroll horizontally, not vertically. The case has been changed from inquiry to bug and is still open.
0 -
Thanks, Toby
Dave
===Windows 11 & Android 13
0 -
Toby Steele said:Dave Hooton said:
What is the intended behavior a width-defined box?
Width-defined boxes are intended to scroll horizontally, not vertically. The case has been changed from inquiry to bug and is still open.
Width defined boxes are effectively useless in 5.1 RC due to the wrapping.
Dave
===Windows 11 & Android 13
0
