|
|
Post by George on Jun 3, 2019 13:14:34 GMT -5
I'll go through this in more detail, but establishing a re-do point is trivial. If you remember, on 3270's various keys triggered what was known as an "Attention Interrupt", which was when the terminal sent it's buffer to the mainframe and received a new screen back. These keys were Enter, PFx, PA1, PA2 etc. All the mainframe did was look at which key triggered the interrupt and if it was PA1, it knew to ignore everything else in the buffer.
SPFLite had to mimic this. While KB primitives are being processed, the last thing they all do is pass through a PostKeyboard routine. In there is a simple test to see if the particular KB routine set the - wait for it - Attention - flag. If not, the routine exits almost immediately back to Windows.
If Set then the whole messy process of examining and processing line commands, Primary commands etc. takes place and the screen is re-drawn. So every time SPFLite does Attention processing, we have our re-do point. The trick isn't establishing when a re-do point is reached, it's figuring out the save/restore logic for PA1.
Mouse stuff is another story.
George
|
|
Ren
Sophomore Member
Retired Mainframer
Posts: 82
|
Post by Ren on Jun 4, 2019 8:49:27 GMT -5
I for one, am always typing on the wrong line, for instance, I make changes, arrow up or down to some other place in the file, without hitting <ENTER>, then start typing more stuff, unfortunately on the wrong line. If I hit <ENTER>, then UNDO, it undoes not only this typing, but also the typing I did on the other piece of the file too. NOT GOOD. An ATTN function (PA1/2/ESC), that undoes what ever I just typed, (this logical screen), and not undo the other changes would be perfect. Thanks.
PS It's my observation that "old" mainframers are more prone to typing on the wrong line then others, because they look at the keyboard rather than the screen, since mainframers are not natively typists, having grown up with coding sheets and keypunchers doing their typing, and are, by in large, hunt and peckers.
|
|
|
|
Post by George on Jun 6, 2019 14:25:37 GMT -5
Ren: Robert:
Next release will have your PA1 support. It had some wrinkles, but was not as bad as I feared.
I could NOT get it to handle PowerType mode however, that is another quantum leap. I think we can live with that.
George
|
|
|
|
Post by George on Jun 7, 2019 12:18:31 GMT -5
Robert: Can't do a swap. PA1 restores the saved data and -- triggers a Display refresh -- which, after the display -- saves it again. I can see your point, but just like PA1 on 3270's, you get one kick at the can.
Also for PT, can't go back since PT Edit could have every line in the file participating, not just lines displayed on the screen. Like I said maybe possible, but a whole major leap to make it work.
George
|
|
Ren
Sophomore Member
Retired Mainframer
Posts: 82
|
Post by Ren on Jun 7, 2019 12:20:08 GMT -5
You guys rock. Thanks
|
|
|
|
Post by George on Jun 7, 2019 12:49:04 GMT -5
Robert: Yes you nag, somebody has to keep my laziness in check.
George
[Update]
Nah! PA1 also does a line command reset, there is no save of these, and the reset is the whole file, not just the lines visible on the screen.
[Update 2]
Round 2. I was thinking, why do we do a full RESET COMMAND? So I tried the multi-PA1 flip/flop with a modified line command reset for just the lines on the screen. I soon ended up down the rabbit hole trying to keep everything straight. Finally bailed out and backed the multi-PA1 stuff out. Sorry.
George
|
|
|
|
Post by George on Jun 9, 2019 14:50:29 GMT -5
Robert: I had everything you describe above in place, and using PA1 as you described to flip/flop screens looked fairly good. Where it went downhill was trying to avoid the full RESET COMMAND activity. There is another piece of the puzzle you don't know about. To improve performance in parsing Line commands and not have to scan the whole file every time, there is a 'touched table' which tracks what line command areas have been altered. Its also used for other line command manipulation.
Trying to adjust for that started the downhill slide. I ended up with line commands not clearing the field on 1st character typed, line commands re-appearing after multiple PA1 keys, extraneous messages for pending commands that weren't there anymore, etc.
As I said, down the rabbit hole. I had forgotten how tricky and involved the whole line command jungle was. I thought I knew how it all fit together so I started to open the code up and 'fix' it. And things just got worse. So I chickened out and went back to the simple PA1.
George
|
|
|
|
Post by George on Jun 10, 2019 12:14:33 GMT -5
Robert: I liked the toggle back and forth with the PA1, I thought I'd put in a compromise.
The first PA1 refreshes the screen and does an internal RESET COMMAND
The next immediate PA1 reverses the screen back - BUT NOT any line commands that were cleared by the 1st PA1.
You can toggle PA1 repeatedly to see the changes in the text (as long as no other intervening keys) and stop and continue with whichever you like, but you can never get back the line commands after they're cleared by the 1st PA1.
Reasonable?
George
|
|
