- Thu Apr 14, 2016 12:42 pm
#45484
I've been hammering away with Alpha 10, and am impressed with its stability.
The main weakness I've found is when trying to create a help page of text.
The first obvious point to mention is that there seems no way to insert more than 1 space between, well... anything on the page, actually. It's not a problem as such, but it does put restrictions on screen appearance.
What is more potentially a problem, even though also not a bug, is the editor line length - or more correctly, the problems that can arise because of it - especially when you have lots of html "strings".
It seems (understandably) that the parser expects each line to start with html (space) and then have a pair of double-quotes "containing the string", presumably then followed by a terminating <BR>.
But if that simple html requirement isn't met - perhaps because of no end quote (easily done by the line wrapping over unnoticed to the line below) or an extra double_quote finds its way in somehow - then it invariably causes the beastie to crash and reboot.
And if you don't know exactly where the problem is in order to edit and save it (once reconnected), then it can be a devil to find, cos it'll keep rebooting on you not just until you do find and correct the problem, but until you resolve ALL OTHER problems that might also be lurking ahead.
Possibly the most insidious are long html lines that DO have the terminating quote " but are somehow missing the terminating <BR>, so the 'html' just happens to wrap itself over to the next line and everything looks perfect, but it is actually all 1 single wrapped over line and the mid-line second html causes inexplicable problems.
I resigned myself to keep inserting strategic ENDs to work progressively down the lines noting whether it exited or bombed. Trouble is that when it bombs and disconnects you need to have remebered to copy and paste from the last edit screen before reconnecting to edit, because it often re-loads corrupted.
Anyway, firstly, a couple of suggestions that might help matters...
a) Could the Edit window have a horizontal slider to allow longer lines without them wrapping over to the next line?
Or
b) If the existing Edit window line length is the max the parser can deal with, could the edit window stop at max length rather than additional typing causing it to automatically wrap down to the next?
And lastly...
Might it be possible to include a Debug facility??
To let you understand where I'm coming from with this...
I was considering doing a separate Basic utility that could parse through a specified file looking for all occurances of html (or print etc) and simply check for correct beginning and end quotes and max line length and <BR> etc.
Then I thought 'but that's what the ESP Basic parser is doing anyway'!
Which led to... what if the parser - or a toothless clone - could parse through the script WITHOUT actually displaying the html contents, but instead just point out any non-compliance errors. It would act like a supplementary error-checking parser which didn't need to involve the existing error-handler or cause a crash.
And that led to... but perhaps it could be done much easier using a separate Debug utility that scanned a named file and reported on whatever errors it might be capable of looking for without actually running the target script? If so, maybe it could be launched from the Edit page.
It wouldn't add anything to the existing ESPBasic dump size (just a button or link), and perhaps there may be other programmers out there who might offer to contribute an initial simple Debugger utility (the rules for checking quoted strings seems to be fairly straightforward),
Hey, you guys are the doers and know what's feasible, I'm just a waffler trying to offer food for thought where possible... but if it was practicaI, it could offer an easy way to provide a very useful added-value debugging facility to ESP Basic.
The main weakness I've found is when trying to create a help page of text.
The first obvious point to mention is that there seems no way to insert more than 1 space between, well... anything on the page, actually. It's not a problem as such, but it does put restrictions on screen appearance.
What is more potentially a problem, even though also not a bug, is the editor line length - or more correctly, the problems that can arise because of it - especially when you have lots of html "strings".
It seems (understandably) that the parser expects each line to start with html (space) and then have a pair of double-quotes "containing the string", presumably then followed by a terminating <BR>.
But if that simple html requirement isn't met - perhaps because of no end quote (easily done by the line wrapping over unnoticed to the line below) or an extra double_quote finds its way in somehow - then it invariably causes the beastie to crash and reboot.
And if you don't know exactly where the problem is in order to edit and save it (once reconnected), then it can be a devil to find, cos it'll keep rebooting on you not just until you do find and correct the problem, but until you resolve ALL OTHER problems that might also be lurking ahead.
Possibly the most insidious are long html lines that DO have the terminating quote " but are somehow missing the terminating <BR>, so the 'html' just happens to wrap itself over to the next line and everything looks perfect, but it is actually all 1 single wrapped over line and the mid-line second html causes inexplicable problems.
I resigned myself to keep inserting strategic ENDs to work progressively down the lines noting whether it exited or bombed. Trouble is that when it bombs and disconnects you need to have remebered to copy and paste from the last edit screen before reconnecting to edit, because it often re-loads corrupted.
Anyway, firstly, a couple of suggestions that might help matters...
a) Could the Edit window have a horizontal slider to allow longer lines without them wrapping over to the next line?
Or
b) If the existing Edit window line length is the max the parser can deal with, could the edit window stop at max length rather than additional typing causing it to automatically wrap down to the next?
And lastly...
Might it be possible to include a Debug facility??
To let you understand where I'm coming from with this...
I was considering doing a separate Basic utility that could parse through a specified file looking for all occurances of html (or print etc) and simply check for correct beginning and end quotes and max line length and <BR> etc.
Then I thought 'but that's what the ESP Basic parser is doing anyway'!
Which led to... what if the parser - or a toothless clone - could parse through the script WITHOUT actually displaying the html contents, but instead just point out any non-compliance errors. It would act like a supplementary error-checking parser which didn't need to involve the existing error-handler or cause a crash.
And that led to... but perhaps it could be done much easier using a separate Debug utility that scanned a named file and reported on whatever errors it might be capable of looking for without actually running the target script? If so, maybe it could be launched from the Edit page.
It wouldn't add anything to the existing ESPBasic dump size (just a button or link), and perhaps there may be other programmers out there who might offer to contribute an initial simple Debugger utility (the rules for checking quoted strings seems to be fairly straightforward),
Hey, you guys are the doers and know what's feasible, I'm just a waffler trying to offer food for thought where possible... but if it was practicaI, it could offer an easy way to provide a very useful added-value debugging facility to ESP Basic.
