Ticket #469 (Open)Mon May 06 22:43:14 UTC 2019
Edit loses characters when sent through keyboard buffer
| Reported by: | Fred Graute (114) | Severity: | Minor |
| Part: | RISC OS: Application | Release: | |
| Milestone: | Status | Open |
Details by Fred Graute (114):
When you send a relatively large number (say 100) of characters to Edit via the keyboard buffer (OS_Byte 138) then every 21st character is lost.
I’ve traced this back to the function ‘txtedit_keyboardinput’ (in RISC_OSLib.rlib.c.txtedit). After having read 20 (=txtedit_AMax) ‘normal’ characters, one more is read. However the variable ‘result’ is not set to 1 so no TRUE is returned, which means in ‘txtedit_obeyeventcode’ (the calling code) the ‘loop_flag’ variable remains FALSE.
With ‘loop_flag’ FALSE ‘txtedit_obeyeventcode’ won’t loop round for more input and the 21th character is lost. Just setting ‘return’ to 1 probably isn’t enough as demonstrated by the next problem.
If 3 control codes are inserted, 0xe,0xf,0×10, then the output in Edit is: [0e][0e][0e] and not the expected [0e][0f]10. This because although ‘return’ is set to 1 in this case, the value of next_e (in txtedit_obeyeventcode) is not updated so on the next iteration the same value (0xe) is placed in ‘e’ at the start of the while loop.
Obviously this needs fixing. Given the speed of modern machines it might be easiest to remove ‘txtedit_keyboardinput’ and have all keys come in via ‘txtedit_obeyeventcode’ and hence via a Wimp_KeyPressed event.
