|
|
Post by Stefan on Apr 16, 2021 13:14:58 GMT -5
Robert, None of this argues against your conclusion re: STATE ON and positioning. I reckon there's issue with STATE at times, having seen some odd things happen. However, I think SPF_CMD("TOP") doesn't quite do what you expected in that macro. Try it with SPF_CMD("LOCATE 0") instead. "TOP" just re-positions the window, it doesn't move the cursor to another line. [UPDATE]
ACTUALLY - this is incorrect and thus hi-jacks this thread. Please see separate post about RESET, TOP, Cursor & Display position
I was irritated by "TOP" for a long time, until I happened to trip over a clue (in the documentation or maybe this forum, can't quite recall) that said that TOP was effectively just an ALIAS for "UP MAX". TOP always bugged me because when I had a lot of excluded lines at the start of the file, I intuitively type TOP ; RESET and that's NOT the same as RESET ; TOP.
The former leaves me looking at the same set of lines as before with lots of, now unexcluded lines, 'above' where I am.
The latter does what I'd expected the former would do, namely show me the file from .ZFIRST on down and the lines unexcluded. Because "TOP" just re-positions the current window, and my excluded lines started with line 1, the TOP command effectively did nothing at all in the former case.
With me, the 'TOP ; RESET' sequence is habitual, which makes me think that ISPF probably equated "TOP" to "LOCATE 0" rather than "UP MAX".
Anyway, I fixed my irritation with a SET ALIAS.top = 'LOCATE 0'
[/UPDATE]
|
|
|
|
Post by George on Apr 16, 2021 15:08:50 GMT -5
Gee! I'd only a while back thought "Wow! Nobody reporting SPFLIte oddities today, miraculous". Fat chance.
I will (tomorrow) look at TOP, LOCATE 0 etc. and see why they're different.
George
|
|
|
|
Post by Stefan on Apr 16, 2021 16:29:45 GMT -5
George, A wild guess, grasping at a thin(!) straw.... Could the OPTIONS setting "Maintain screen position after line commands" have a bearing on how TOP operates these days? I know the behaviour relating to top is the same with that setting ON or OFF, but is the code somehow influencing the positioning?
|
|
|
|
Post by George on Apr 17, 2021 10:52:17 GMT -5
OK, this is a case of you can't have your cake and eat it.
We complained about STATE LOAD not positioning TopScrn properly, so I fixed that.
Now we have a problem --- STATE ON and START FIRST. (Or several of the other START xxxx options)
Which one do you want to whine about?
Oh, it also has absolutely nothing to do with the "Maintain Screen position after line commands"
George
|
|
|
|
Post by George on Apr 17, 2021 14:42:49 GMT -5
Robert: I'm not going to go search for whatever threads triggered this. Somebody complained that opening a file with saved STATE data was not positioning the file according to the TopScrn line number saved in the STATE file.
So I plugged away and finally got the STATE version of the Topscrn line number to properly take effect.
Now however, it seems that action 'collides' with START XXXXX processing. Which should win? START FIRST? or the line number saved by STATE?
Frankly I feel that all the effort I put into finding out why the STATE top of screen line wasn't working was a total waste of my time. Simply because I hadn't considered the START FIRST aspect.
I'm getting real tired of chasing these niggling "it's not quite perfect" bugs, they take a ridiculous amount of time to resolve. And then to find that it's not really a bug, but a design decision is a real p*ss-off.
Sorry to be so blunt, I've just come off another 5 hour session figuring out how to have the Crash handler do a save when the crash was a loop.
As to the STATE vs START problem -- START I believe was created before STATE, my feeling is that START should be retired. If you want positioning at open time, turn STATE ON.
George
|
|
|
|
Post by George on Apr 17, 2021 15:45:06 GMT -5
Robert:
Sorry if I'm a bit 'testy', but looking back on this particular 'bug', I believe I've wasted an inordinate amount of time on it.
And now it still needs some kind of resolution, so the wasted time continues.
It seems now that the bugs reported are getting more and more obscure, and isolated to some user's individual command usage pattern and their expectations. These are simply getting into the 99% of the work to find 1% of the problems vein.
Maybe I'm just getting tired, debugging and tracing stuff through the code is NOT exactly enjoyable work, no matter the result.
George
|
|
|
|
Post by George on Apr 19, 2021 13:44:19 GMT -5
Well, when the SPF_Cmd("TOP") didn't work, it's a shame nobody tried inserting an SPF_Trace(ON) statement. It comes out very nicely with a failure that says "TOP is not allowed in Macro Mode".
Now corrected (along with BOTTOM)
George
|
|
