|
|
Post by Stef on Nov 4, 2016 13:42:44 GMT -5
Reported against v8.4.6153 but noticed on previous versions
There are consistency issue with the 'BOUNDS' and 'BNDS' dialogs leading to several odd effects. The following examples assume file opens unbounded...
(1) It is difficult to "change" the BNDS line.
Open file
Type line command 'BNDS'
-> Shows current Bounds, ie. "< +"
Type prim command 'BOUNDS 10 50'
-> BNDS line shows left 10, right 50
Type on the BNDS line, e.g. change "<" to a blank or a blank to "<"
-> BNDS line display goes corrupt and also shows one of several error messages relating to BNDS line (depending on what you did)
Press ENTER/RETURN
-> shows bounds are unchanged
Type anything at all on the BNDS line, e.g. "xxx"
-> BNDS line display goes corrupt, "xxx" is added to future corrupt BNDS display
(2) Primary command 'BOUNDS' and 'BOUNDS MAX' do not work as designed.
Open file
Type line cmd 'BNDS' and change the default "< +" display to " < >" (e.g. col 7 - 16)
Type prim cmd 'BOUNDS' or 'BOUNDS MAX'
-> Msg "Bounds reset to defaults", but BNDS line & Bounds setting remain unchanged
but...
Type prim cmd BOUNDS 1 MAX
-> it works correctly.
|
|
|
|
Post by George on Nov 15, 2016 11:17:13 GMT -5
Stef: Hmmm, there's certainly something weird happening. I'll check further.
George
|
|
|
|
Post by George on Nov 15, 2016 16:35:03 GMT -5
Stef: Had a look. This routine has been re-written several times over the years, and I was sure the last re-write was pretty exhaustive. So I started tracing it through and quickly discovered a quirk of PowerBasic (which SPFLite is written in). It may be a compiler bug, not sure, I have to read the doc a little closer. But I ended up with a LOCAL variable in the BNDS method which duplicates an INSTANCE variable of the whole object. Result was a complete mess. I've renamed the LOCAL variables to be unique and it seems to be back to working.
Meanwhile, if changing BNDS on the actual BNDS data line, do an EraseEOF of the line and re-enter what you want. This change will come out in the next release.
George
|
|
|
|
Post by Stefan on Apr 26, 2017 6:47:55 GMT -5
Hi George,
I appreciate this may still be work in progress, but here are related observations from version 8.5.7027...
The primary BOUNDS and line command BNDS interaction does not reflect the bounds settings accurately.
(1) If restricted bounds are set using the BNDS line command, and subsequently the primary command BOUNDS MAX or just BOUNDS (without operands) is issued to reset them to default, the message "BOUNDS reset to defaults" is issued, but the bounds setting, as well as the BNDS line display and the status line display, remain unchanged.
(Note: "BOUNDS lft rght" or "BOUNDS 1 MAX" works correctly)
(2) The HELP file states that "default" bounds means "1 MAX", but the "BOUNDS MAX" or just "BOUNDS" command resets bounds to the values recorded in the PROFILE which were applied when the file was loaded. So once an edit session was closed while restricted bounds were in effect, it cannot be easily be reset to default by primary command (unless the full "BOUNDS 1 MAX" is used).
As for BNDS line command changes discussed previously...
Anything typed on the BNDS line is likely to be flagged "extra or invalid" on second and subsequent changes to the BNDS line within the same edit session, because previously entered settings (or even invalid characters) re-appear in the BNDS line as typing commences. I appreciate the EraseEOF workaround, but that means one needs to (re)enter both bounds, even if only one is being changed.
Why does the BNDS line show anything except the markers for currently active bounds as soon as one starts to overtype it? The history isn't important for the BNDS line process (although maybe it needs to be kept for UNDO purposes but then not in the BNDS line). Is it perhaps simply a case of "re-drawing" the/(all?) BNDS line(s) after a change was made, so as to contain markers reflecting only the active bounds?
Example:
a) Load a file into the editor
b) Enter primary command BOUNDS 1 MAX
c) Enter line command BNDS on line 3
d) Overtype BNDS line to set bounds to cols 10 to 30 & ENTER -> all ok
e) Overtype BNDS line to set bounds to cols 5 to 45 & ENTER -> still ok
f) Overtype BNDS line to set bounds to cols 15 to 60 & ENTER -> message Invalid or extra characters in BNDS line
The "extra" chars are leftover "<" and ">" marking the bounds set by the earlier two BNDS changes.
|
|
|
|
Post by George on Apr 26, 2017 10:37:58 GMT -5
Stefan: Yes indeed, it seems BOUNDS needs yet more work. Man, I'm getting tired of re-writing that piece of code, it seems so simple, but it also seems to have me buffalo'd as far as getting it right.
George
[UPDATE]
This gets ugly very rapidly. When the keyboard is in INSERT rather OVERTYPE, the current logic to spot what's changed in the BNDS line falls apart very rapidly since existing < > and + characters get shifted, and now appear to be altered, making it impossible to tell "what's new". Especially hard to edit if the old value had Right Max, since any insert pushes the + off the right side of the screen, hiding it.
Have to think about this. I have a feeling whatever I put in, I'll get "why didn't you ... " responses.
George
|
|
|
|
Post by George on May 1, 2017 12:22:49 GMT -5
BNDS changes.
There were multiple problems in the BNDS code.
I think I have fixed them all, but in the process I have removed entirely the logic which allowed over-typing parts of the BNDS line and leaving the program to figure out what characters were just entered, and what characters were 'left over' from the previous BNDS data.
With KB Insert mode shifting previous characters as you typed, this became (for me) just too difficult. The validation is not done as you type, but the next time Enter is pressed.
Basically, when you press Enter, the BNDS line must be valid as it sits. Since all a BNDS line requires is 2 characters to be valid, I don't think is too much to ask.
George
|
|
|
|
Post by George on May 2, 2017 11:56:47 GMT -5
More importantly, this isn't about how BOUNDS itself operates once set, but about how 'flexible' the parsing of the BNDS line should be. Our attempt to 'figure out' what was wanted when the BNDS line contained a mixture of old values and new overtyping was trying to be a bit more clever than was worth it. As I said, entering just two characters on the line to make a valid request isn't exactly a difficult task.
George
|
|
|
|
Post by George on May 3, 2017 11:24:35 GMT -5
Robert: What you describe is correct, that's what the old logic was attempting to do. One of the problems I discovered was that the BNDS line was not always being updated correctly on screen, causing confusion.
The other error more typically happened when the existing bounds was BOUNDS n MAX and we place the + sign on the right hand side of the screen. Using INSERT mode the first thing that happens is the + gets pushed off the screen and becomes invisible. Then if a pair of < > are entered you get an error complaining about having both > and +, yet no + is visible.
Basically insert/delete of what's on the line in combination with some changed characters makes for an overly messy and complicated parser. All for what - to parse a requirement for two characters on a line? We were trying to be 'nice' and helpful, sure, but doing all this for BOUNDS, a feature that even we disparage and discourage, is just not worth the multiple re-writes and tweaks.
George
|
|
