|
|
Post by Jo on Oct 3, 2021 16:17:46 GMT -5
Most of my profiles have START PRIOR and STATE ON or STATE MOST. On some files/filetypes I found that STATE PRIOR did not work recently. Now I'm on v2.5.21274 but I'm unsure when I first saw this. Some filetypes work as expected, START PRIOR is honored (and I see the current LinePos in the .STATE file). Filetypes not working (always save a current linepos "1" after the totallines in .STATE) all have a PROF USING. Filetypes not having PROF USING seem to work.
Jo
another problem found during testing: when there are =PROF> lines before the current line, they are still counted and the saved current linepos is therefore too high.
|
|
|
|
Post by George on Oct 4, 2021 8:54:28 GMT -5
Leave it with me.
George
[UPDATE]
The problem with PROF lines being counted is fixed.
I see nothing wrong with files with Using. e.g. my own .INC files have USING(BAS). Positioning seems to be working fine with START PRIOR. I'm not clear when you say they have a linepos of 1. You mean the STATE file shows 1 even though the file was positioned elsewhere?
[\UPDATE]
|
|
|
|
Post by Jo on Oct 4, 2021 15:54:27 GMT -5
George, yes, the 3rd item in the #10 STATE line seems to be the linepos for START PRIOR. This value is 1 and always is 1 even after the file was positioned elsewhere. Jo
[update] and yes, I also found a profile with USING not having that problem:
PROFILE ASM USING(AVRASM) UNLOCKED, - problem occurred
PROFILE INC USING(AVRASM) UNLOCKED, - no problem
PROFILE REX USING(OOREXX) UNLOCKED, - problem occurred
?? Jo
|
|
|
|
Post by George on Oct 5, 2021 9:19:57 GMT -5
Thanks Jo, I'll continue my search.
How is the session terminated? A simple END? A right-click on the tab? A macro or DO request? A SAVE then CANCEL?
Just noticed in the code. If part of a MEDIT session, it is always set to 1. Is MEDIT involved?
|
|
|
|
Post by George on Oct 5, 2021 9:59:25 GMT -5
Jo: OK, found it (hopefully). It seems to be localized to the STATE saving done by END, when the file is still in unmodified condition. That area was always a bit convoluted, and the revisions lately to how the global search routine criteria are handled added some new wrinkles.
I'll be posting a new Beta today.
George
|
|
|
|
Post by Jo on Oct 5, 2021 15:15:56 GMT -5
George: Yes and yes. It was on END (or EXIT) in BROWSE or unmodified EDIT. And it works again (v2.5.21278). Also the problem with PROF lines is solved.
Thanks !
Jo
|
|
|
|
Post by Jo on Oct 5, 2021 17:05:57 GMT -5
Oooops, when ENDing an EDIT session with modified data and AUTOSAVE ON PROMPT, then YES
the STATE saving is still setting '1' as top-of-screen position (v2.5.21278).
Jo
|
|
|
|
Post by mueh on Oct 6, 2021 1:47:56 GMT -5
George: STATELOAD crash problem with 21278 after
LOC 5 TOP
PROF
the prof lines are on top of screen before Data line 5 .
Ending the tab results in STATE Lptr of -6 and crash on restart unless - in STATE or STATE is deleted .
Wouldn't it be simpler to use Line Number ( LNum ) of first Data Line on Screen in STATE instead of calculating LPtr ?
Thanks
|
|
|
|
Post by George on Oct 6, 2021 9:04:32 GMT -5
Jo: As I said, convoluted logic. Walked a debug through the path and yep! missed one route. There is however one combination to watch for.
With AUTOSAVE ON PROMPT, if you reply NO to the Save itself, that leaves the file in the modified state, and STATE creation is always bypassed for modified files.
Thanks for spotting it.
George
|
|
|
|
Post by George on Oct 6, 2021 9:40:23 GMT -5
MUEH: Yes, but the STATESAVE problem was a bit more pervasive. All the special lines (PROF, MASK, TABS, etc.) were affecting the TOS position saving.
Basically all Special lines ABOVE the TOS have to adjust the TOS value. Revised the code and it now appears much better.
George
|
|
