R60
Freshman Member
Posts: 32
|
Post by R60 on Mar 22, 2015 17:57:57 GMT -5
Please have a look to the PDF attachment, and tell me if you need more info.
SPFLite Req_005.pdf (294.42 KB) |
|
|
|
Post by George on Mar 23, 2015 11:29:04 GMT -5
R60: My, we are being nit-picky here aren't we? You pressed Enter, the lines went away. What you're complaining about is the internal logic flow I use vs the flow ISPF uses.
I clean up Insert lines when all line command and primary command activity has been completed. It appears ISPF must do it before all commands are complete, and I believe this is actually an error on ISPF's part.
For example:
Set the MASK value to " /* */" so new lines start with a comment block
Do an I8 as you have done.
Enter the command CHANGE ALL ' ' 1 'X' and press enter.
If I remove the I lines before primary command processing, the I lines would have been removed and the change command would do nothing. (and I'm sure you would be complaining about that fact)
The anomaly you saw is simply because you performed the rather odd sequence of inserting lines and immediately doing a SAVE. But rather than accommodate this highly unusual behavior just to keep you happy, the sequence I use will remain and not be altered because it is the correct thing to do. I will not slavishly follow ISPF's flawed method.
George
|
|
R60
Freshman Member
Posts: 32
|
Post by R60 on Mar 23, 2015 15:13:55 GMT -5
George:
I don't think this is 'nit-picky'. Please remember that after the SAVE only 2 lines are displayed, which does
not reflect the current data in the saved file (it holds the 10 lines !!!). If you show me the 'true' 10 lines (as saved)
may be I could agree and it's more on the way to be 'nit-picky'. And if you say it's an error on ISPF - I like this
error, because ISPF never save any data on 'not touched' inserted lines.
Sorry about that, but I became accustomed to the ISPF behavior for more than 30 years (if it's a flawed method - or not).
I have tested some (but only some, because it's time-consuming) of your extensions (compared to std. ISPF) and
some of them are very nice. But for the basics I expect the standard ISPF behavior, because you also say that
SPFLite is a ISPF 'clone'. Sorry, but this is my opinion...
I will continue my testing and tell you other errors/incompatibilities - if you like.
Btw: And thx for the phrase 'nit-picky', because you know that this is not my native language - so a dictionary
was required - and it's not to late for me learning new things like 'nit-picky'...
And in the future I should tell you more about the goodies of your version, because you do a good job.
|
|
R60
Freshman Member
Posts: 32
|
Post by R60 on Mar 23, 2015 16:36:32 GMT -5
George:
Yes, you are right - there is a different behavior ISPF/SPFLite !!!
Okay, I re-read your answer and my comments and do some more testing on this.
Assume MASK is blank and 'i8' is typed as a line command.
Then I try your command CHANGE ALL ' ' 1 'X'.
In ISPF -> only the ' ' on position 1 is changed to 'X' on existing lines.
Not on the new 'i8' lines. This makes sense to me, because the 'i8' lines are
not valid data lines, because they are not touched until now. The same happens to a
MASK value of " /* */" (like your example). And again, this makes sense to me,
because this lines are not touched until now. That's the ISPF behavior, and this
is okay for me. There is no data in the INSERT-marked lines, so it can not be changed.
In SPFLite -> the change is applied to the 'i8' lines. This is not okay for me, because
the 'i8' lines are only 'placeholders' until anything is entered in the
'placeholder' positions. So, this could be the next bug - "Changes which could be
applied to non-existent data..."
In CTC (my version) -> same behavior as ISPF.
I hope you understand what I like to say. And I think the ISPF behavior is correct,
because INSERT-marked lines do not exist until touched.
Please re-think about it and give me a reply. Thx.
That's it for now, because I don't like to read the IBM manuals for the INSERT line
command to find more arguments why the ISPF handling looks okay to me.
...my be later on...
|
|
R60
Freshman Member
Posts: 32
|
Post by R60 on Mar 24, 2015 9:43:30 GMT -5
Robert: ...'hardly picky'...? Yes, may be sometimes...
And thx for your nice comments on the "temp" record lines.
As you say "a temp line is no real data line", that's it!
Let's wait for George...
|
|
|
|
Post by George on Mar 24, 2015 11:23:51 GMT -5
R60: Robert: OK, by strict interpretation of the definition, I will accept this as a bug, and it has been corrected. But a bug in this basic a function which has been in existence since V1.0 of SPFLite, and which has never been noticed, or mentioned in any way by any user in all those years tells me this is not exactly a critical error.
As to SPFLite being a 'clone' of ISPF; if that is supposed to mean SPFLite will exactly follow the ISPF lead in every aspect of it's operation, then let me put that to rest. That has never been my intention, never will be. Although not in the current web site layout, the original web site described it correctly "SPFLite - A Windows editor for ISPF lovers". It's supposed to provide a familiar interface which ISPF users can quickly adapt to, based on their ISPF experience. The keyword in there is 'adapt'.
George
|
|
