|
|
Post by George on Jul 31, 2021 14:24:32 GMT -5
Robert: Wow! This is a real old 'lurker' bug. It has to do with clicking a new cursor location with the mouse.
It's one of those if this, and that, and something else and something further, then .....
Basically, if you click on a data column number that is less than the width of your line number field, it fails.
This is all wrapped up in how dragging selection areas with the mouse works, but basically it was a really dumb Oops!
George
|
|
|
|
Post by George on Jul 31, 2021 14:52:30 GMT -5
Robert: The BS works as expected with the fix. What basically happened is that with the bug, a simle click in the low columns acts as if you clicked and dragged a 1 column selection area. Then BS takes that as a request to delete it.
BS was not the problem, it was mouse selection gone astray.
George
|
|
|
|
Post by George on Aug 1, 2021 8:46:59 GMT -5
Well, it only failed for me when setting the cursor with the mouse. It always worked when using only the KB. Checked the latest fixed version, I can see no problems with BS. See if you can break it, again. George SPFLite25.exe (512.5 KB) [UPDATE] Forgot to mention, if you try this version out, don't go back to the previous version, stay on it. There is an upward only compatible change to STATE handling. [\UPDATE] |
|
|
|
Post by George on Aug 1, 2021 11:01:38 GMT -5
Robert: To go back, you'd have to revert a file and it's STATE file together.
What's happening is I've finally had it with the old STATE Hash routine. It's an ASM routine with its own ASMDATA table.
Works just fine - EXCEPT in Debug mode, where the INT 3 instructions inserted to support stepping through code muck up the ASM and it's data tables. Making every file a STATE error and every file saved in DEBUG a STATE error when back in normal execution mode. Drives me nuts.
So for my own sanity, the Hash routine is changing. It's only for my benefit, not the users, so I'm invoking executive privilege.
The new version will accept files using EITHER hash method, but all new STATE is written using the new hash routine. So if you stay on the new version (and all subsequent ones) it is transparent.
George
|
|
|
|
Post by George on Aug 1, 2021 13:21:29 GMT -5
You may be right, and this might be a time to make some changes.
But most STATE errors already still attempt to proceed. What kills STATE totally are:
a) Line count mismatch (I don't think this can ever be recovered from)
b) Structure errors, e.g. The order of STATE record types is out of sequence. Like Labels come first, tags come second, etc. These are indicative of a corrupted STATE file.
Hash errors on their own never kill a STATE load totally.
So I'm not clear what else can be relaxed.
George
|
|
|
|
Post by George on Aug 2, 2021 9:47:16 GMT -5
Robert: During SAVE, STATE is always saved during the whole SAVE process (assuming STATE ON).
But STATE is also saved on END (with or without SAVE) as this was an 'improvement' we instituted last year I believe. Also done when an explicit STATE SAVE is done.
George
|
|
|
|
Post by George on Aug 2, 2021 13:24:22 GMT -5
Robert: Before we go off on a witch hunt looking for a culprit, are we sure there's a problem? Since the last set of fixes for STATE saving, I have not had a STATE failure. (I'm ignoring the ones I get triggered by DEBUG / non-DEBUG mode, I understand and expect them with the production version, and nobody else will experience this type)
But you seem to be indicating you get them all the time.
Lets hear from some other users - are you still getting STATE errors when you believe nothing but SPFLite has edited the file?
The latest set of fixes, which are in 21186, were put in after I spent an extensive amount of time reviewing and testing STATE activities. If indeed there seems to still be lurking pronlems, then I've run out of ideas for where to look, I've exhausted my list of possibilities in that last update.
Give me some clues, some scenarios that trigger failure, some ideas where you think the error might be hiding and I'll happily chase them. Asking me to review it all again is a non-starter.
George
|
|
