ca055@unocss.UUCP (David B. Caplinger) (02/15/88)
Sorry if this is a dumb place to put this, but I don't know where /else/ to send it... I'm trying to run a process in the background (via spawn/nowait/noinput) that takes over the top 4 lines of the screen, sets up the scroll region below that (so it won't get erased), and update the display on top every 30 seconds. The only problem I have so far is: The cursor never goes back to the original position after the background process updates. Sure, I used ESC 7 and ESC 8, but the cursor still winds up on the beginning of the next line, after scroll- ing the lower region. Argh! (I added a reverse-index at the end, and now it's on the same /line/ at least, but the coloumn is still wrong.) Is there any way to make sure the cursor position is retored /where it left off/, instead of the next line? (Perhaps it /is/, and it's getting moved somehow? Has anyone else had a problem like this?) -/ Dave Caplinger /- ihnp4!unocss!ca055 (preferred) unocc07@zeus.unl.edu
cfchiesa@bsu-cs.UUCP (Sir Xetwnk) (02/16/88)
In article <240@unocss.UUCP>, ca055@unocss.UUCP (David B. Caplinger) writes: > [background on cursor-positioning problem...] > > The cursor never goes back to the original > position after the background process updates. Sure, I used ESC 7 and ESC 8, > but the cursor still winds up on the beginning of the next line, after scroll- > ing the lower region. Argh! (I added a reverse-index at the end, and now it's > on the same /line/ at least, but the coloumn is still wrong.) > > Is there any way to make sure the cursor position is retored /where it left > off/, instead of the next line? (Perhaps it /is/, and it's getting moved > somehow? Has anyone else had a problem like this?) Yes, Dave, this is a common problem under the very circumstances you describe. The ESC 7 and ESC 8 are doing their jobs -- the cursor position is doubtless being dutifully saved and restored as you intend -- BUT, I'll bet you a cookie you're writing the ESC 7 and ESC 8 to your terminal, using a language and statement which is appending a carriage-return (CR) and line-feed (LF) to its output; that's what's messing up your cursor position, and here's why: ESC <whatever> restores the cursor to its saved position; so far, so good. But immediately there follows a CR, which moves the cursor to the leftmost column of the line, and a LF which moves the cursor down one line. Presto; the cursor is "nowhere near" its intended position, even though you're sending out precisely the right escape sequence. You've overcome the Line-feed problem by sending the 'reverse index' sequence; this "anticipates" the effect of the LF, and can be thought of in essence as an "UN-linefeed" operator. But unfortu- nately, there's no corresponding "UN-carriage-return" operator; once that CR hits the screen, your cursor is moved, period. (Does anyone know of any excep- tion to this statement? If so, let me know!) In order for your ESC 7 and ESC 8 to have the intended effect when written from your program, you need to output them WITHOUT appending LF or CR. In many of the "high-level" languages under VMS, this seems to be surprisingly diffi- cult to achieve. The only languages in which I've seen it done directly, using only features built into the language itself, are BASIC, FORTRAN, and (if this counts) MACRO. In Pascal, forget it; in COBOL, who knows? You can't do it at all in DCL, which is probably because DCL isn't really a "programming lan- guage" in the first place. You can either a) write in BASIC and use the semicolon (;) terminator on your PRINT statements; b) write in FORTRAN and use whatever it is that FORTRAN carriage-control syntax uses for "don't move the (cursor, or carriage) after writing"; c) use the $QIOW system service from whatever language (other than DCL) you're writing in; d) have someone write a routine to perform the desired output, in a language which supports it, and call this routine from your pro- gram. I've written a MACRO procedure which allows carriage-return-less, line-feed- less string output from Vax Pascal programs; if you (or anyone else) is interes- ted in receiving a copy, e-mail me at the address below. Chris Chiesa Senior, CS Dept. Ball State University Muncie, IN <><><><><><><><><><><><><><><><><><><><><><><><><><><><> Chris Chiesa <><><><><> <> {ihpn4|seismo}!{iuvax|pur-ee}!bsu-cs!cfchiesa <> <> cfchiesa@bsu-cs.UUCP <> <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
rbl@nitrex.UUCP ( Dr. Robin Lake ) (02/26/88)
In article <2124@bsu-cs.UUCP> cfchiesa@bsu-cs.UUCP (Sir Xetwnk) writes: >In article <240@unocss.UUCP>, ca055@unocss.UUCP (David B. Caplinger) writes: > >> [background on cursor-positioning problem...] >> >> The cursor never goes back to the original >> position after the background process updates. Sure, I used ESC 7 and ESC 8, >> but the cursor still winds up on the beginning of the next line, after scroll- >> ing the lower region. Argh! (I added a reverse-index at the end, and now it's >> on the same /line/ at least, but the coloumn is still wrong.) >> >> Is there any way to make sure the cursor position is retored /where it left >> off/, instead of the next line? (Perhaps it /is/, and it's getting moved >> somehow? Has anyone else had a problem like this?) > >Yes, Dave, this is a common problem under the very circumstances you describe. >The ESC 7 and ESC 8 are doing their jobs -- the cursor position is doubtless >being dutifully saved and restored as you intend -- BUT, I'll bet you a >cookie you're writing the ESC 7 and ESC 8 to your terminal, using a language >and statement which is appending a carriage-return (CR) and line-feed (LF) >to its output; that's what's messing up your cursor position, and here's why: > > [Edited for brevity.] I believe you can also set the terminal (momentarily) to PASSALL, send the 2 bytes, then reset it with NO PASSALL. We had the inverse problem with some PostScript printers. -- Rob Lake {decvax,ihnp4!cbosgd}!mandrill!nitrex!rbl