Make Mine MAPPER #17 -------------------- by Rob Haeuser Screen Control (SC): A Universe Unto Itself? ---------------------------------------------------------------- Sometimes the hardest part of writing an article is naming the blasted thing. Occasionally I'll pass possible titles by fellow MAPPERites to get their reactions. Such was the case the other day when I got the comment: "What the heck does "Nya Nyuniverse Nyunto Nyitself?" mean?" Obviously a feeble attempt to ridicule a thought provoking idea, since this person could speak normally when pressed. "Whadaya mean, nya, nya, nya?" (I can thank my two little boys for that quick come-back.) Guess I'll have to explain it. "Cheeeeeez, man. It's like, you know, like, wow, man, because like, SC's a Zen function, sort of, you know what I mean, man?" Valley talk seems to work with this guy. "Oh. You mean that rhetorically, then, don't you, because if you're talking about MAPPER's screen control run function, it couldn't possibly be connected to Zen, because, religiously speaking, blah blah blah, and blah blah blah....". Pressed the old magic button again, didn't we? "Well, yes, of course it's rhetorical! Aargh! What the title is trying to suggest is that MAPPER's screen control function (SC) is so powerful, with so many capabilities, that it might almost qualify as a programming language. Or, at least, it raises the question: who needs all those other screen functions, with SC around? Or something like that." I don't think he's gonna get it... Then Mr. Brilliance spouts: "It's part of MAPPER run design, isn't it? So, sure, SC is a programming language. For screens." Mmmmm. Thank you soooo much. I enjoy these little brainstorming sessions, can't you tell? "So you hate the title then, eh?" I had accepted defeat. "Nah, I kinda like it. My thoughts are getting provoked." Nnnnnyyaahhrrggg!!! I can't believe this! Oh... Oh, great. Now I've forgotten what it was I was gonna write about! SC, SC. Lemme see, SC. Hmm. It's Christmas time; maybe that's it. SC. Must stand for Santa Claus. Nah, can't be. Hmm. Oh well. Until the topic comes to mind, maybe we could talk a little bit about SC, MAPPER's screen control function. (Why do those two letters keep ringing in my ears?) We first touched on SC back in the April, 1991 issue of Unisys World with the article "Monochrome Monotony: Gimme GUI, But SC'll Do, Too". In it I gave my forecast for the future of graphical user interfaces (GUIs) by stating that "most applications could live without a GUI forever". Apparently the crystal ball hath cloudeth. It is no small irony that April was also the month of the spring Use conference, at which Unisys announced the Designer Workbench, a GUI glue between MAPPER and Microsoft Windows. It promises to make using a GUI so simple that character displays will become obsolete... ...Not! Well, at least, not for awhile. Ok, so maybe I need to put on a donkey head for that one, but I still say there's plenty of life in them thar hills... of characters, that is... for SC to play with. It'll take quite a few years for the world to convert to full-color-touch-screen, instant- voice-recognition-regardless-of-accent, read-my-thoughts-or-at- least-my-lips-you-think-you're-so-smart-I-hate-you-for-making-me- feel-inferior technology, don't you think? So, on with the show! SC is one of a few MAPPER run design screen functions, including: @DSM (display system message), @DSP (display a report), @OTV (output to video), and @OUT (output). In fact, in virtually all cases, SC can replace these other functions, even @DSP. Granted, there isn't always a good reason to do so. SC may be more tedious than using a function specifically designed for the need at hand. Admittedly, I have not used OUT to code a screen in well over a year and a half. OTV was never high on my list of heavily used functions: it seems most useful in sending special characters to the terminal to interface with the control page, which SC can do with it's CP (control page) command. I tried DSM to display error messages for awhile, but DSM is like OUT in that it requires the output to be located in a rid somewhere. I never liked having to create a report with an error message in it, just to be able to display it. Or to read some magic line number from a permanent report that has a list of all known errors (there are definite advantages to this approach for larger systems). SC's MSG (message) command can replace DSM in any case. So, even though we probably could, we don't want to replace all those other functions with SC. DSP is still handy, and there are occasions for using combinations. At TDHS we have a little utility run called the Rid Handler (RH). It uses a combination of OUT, DSP, and SC to display a report with a function key bar (described in Figure 1). It was written using level 34 SC capabilities to simulate some of the look and feel of level 35. --------------------------------------------------------------- FIGURE 1 -------- Function key Action ------------ ----------------------------------------- 1 Page Down (roll forward 22 lines) 2 Page Up (roll backward 22 lines) 3 Shift > (to the right up to 79 columns) 4 Shift < (to the left up to 79 columns) 5 Print (displays an input screen) 6 Top (display jumps to the top line) 7 Bottom (display jumps to the bottom line) 8 Help (for using the Rid Handler) 9 Control (gives manual MAPPER control) 10 Return (to the calling run or release) --------------------------------------------------------------- RH is accessible via three different mechanisms. It can be executed as a stand-alone run, linked by another run with the LNK function, or it can be called as a subroutine via RSR. It can be passed parameters indicating which line number to start displaying from, how many lines to hold on the display, which pre-defined format to use for the display, and a station number, printer site, and banner page for printing. The intention was that RH would be used not only as a display mechanism for people unfamiliar with manual MAPPER functions, but that systems with a need to display reports could do so without automatically opening up the vulnerable world of manual display. This became especially useful when I modified RH to return a line number if the user transmitted in the body of the report. For example, a run could display a table of values because a user entered a question mark on an input screen. The user can then peruse the list, transmit by the desired entry, and the run can then read that entry from the table, placing the value on the screen automatically. We don't have space to get into a detailed look at all the code involved, but it's just a bunch of variable stuff, anyway. The SC code is shown, uncompressed for clarity, in Figure 2. A simplified example of how RH works in demonstrated in Figure 3. --------------------------------------------------------------- FIGURE 2 -------- DEF,1,LI,PR,RV,RED/CYA (Define screen attribute set number 1) DEF,2,NI,WHI/BLU (Define screen attribute set number 2) DEF,3,PR,NI,YEL/BLA (Define screen attribute set number 3) DEF,4,PR,NI,RV,WHI/RED (Define screen attribute set number 4) ATT,PR (Set attribute to basic protected) PC,1,31 (Position cursor to row 1, column 31) ATT,1 (Turn on attribute set 1) '' << Rid Handler >> '' (Literal to be displayed on screen) ATT,PR (Reset attribute to basic protected) PC,2,1 (Position cursor to row 2, column 1) ATT,2 (Turn on attribute set number 2) PC,24,1 (Position cursor to row 24, column 1) ATT,UE (Unprotect the bottom line) EEL (Erase to end of line) ATT,3 (Turn on attribute set number 3) ''F1'' (Literal to be displayed) ATT,4 (Guess) ''PgDown'' (Literal in FunKyBar position 1) ATT,3 (Guess again) '' 2'' (Literal preceding FunKyBar position 2) ''PageUp'' (Are we having fun yet?) ........... etc, etc, toggling attributes and literals......... ''Return'' (Literal in FunKyBar position 10) HC (Home cursor) ---------------------------------------------------------------- ---------------------------------------------------------------- FIGURE 3 -------- @RNM -1 . . . . .(Establish reference to report being displayed) @IF . . CHG INPUT$ . . . . . . . .(a bunch of code to get input) @SC Q PREP . . . . . . . . (Prepare the screen - clear it, etc.) @BRK . . . . . . . . . . . . . . . (Clear the output area, etc.) . . . . ALL THAT SC STUFF GOES HERE, COMPRESSED, OF COURSE . . . @BRK RNM -2 . . . .(Create a result of SC code and rename it -2) @CHD . . . . . .(Turn on command handler; piddle with variables) @FMT,-1 . . . . . . . . . (establish the format to be displayed) @IF . . OUT,-1,L,Q,1,,,Y ; . . . .(Use OUT if headers were held) @DSP,-1,SL,,FMT,Y,HL . . . . (Interim DSP to display the report) @KEY SC,-2 '' . . (Overlay the report with color and a FunKyBar) @IF FKEY$ = 1 . . . . (What function key was pressed, or did the @. . . . . . . . . . .user transmit, and what to do about it...) ---------------------------------------------------------------- A lot of code was omitted, of course. The order of events boils down to this: if need be, an OUT is used to output "held" lines. Then, an interim display actually puts the data on the screen. Finally, an SC gives the screen color and creates the function bar. The command handler (CMD) prevents the user from accidently breaking out by transmitting on the control line. Including the built in print screen, the actual code amounts to about 75 compressed lines. It would probably be a few hundred if it were uncompressed. One note of interest is the "SC Q PREP" line used to clear the screen. The natural tendency would be to include the PREP as part of the SC code saved in -2. However, if that were the case, the data just displayed via DSP would get erased! And You can't rely on OUT to do it, because it's execution is conditional. Here's a couple of ideas for all you brainiacs to ponder New Year's Eve when the party starts to bore you: the first four lines of DEFs in Figure 2 show the colors hard-coded. These values, as well as intensity, could have been contained in variables, loaded from some rid somewhere that could store user-selected color combinations. Gee, you don't suppose that somebody has written a run to define a screen with eight areas, such as title, border, interior, input fields, sub-windows, and a function key bar, which then solicits color combination schemes as input from the user to store for later reference, do you? ...Written in all SC code? ...That runs under level 34? ...That comes with a subroutine accessible by any run that wants to use a pre-determined set of variables for these screen color/intensity areas? ...And that they called it the Universal Color Utility (UCU)? And here's another one for you: SC's FKEY command creates a function key bar for you, right? F1 through F10 show up ok, but what about F11? Nope. But, as demonstrated above, we can create our own function key bar, hand tailored to the specific need. As easily as we loaded a "2" for position two, we could have loaded a "12". Same thing for the literals, using variables, of course. So F10 could be "FKyTgl" for "Function Key Toggle", and the run would simply alternate between function key bars when F10 was pressed, indicating functionality for up to 20 function keys. Well, if you haven't guessed by now, SC is alright with me. Can you believe there are 44 pages in the manual on SC? It may not be it's own universe, but it can sure make you feel like you have more control over your own! Have a Happy New Year!