Make Mine MAPPER #10 -------------------- by Rob Haeuser Monochrome Monotony: Gimme GUI, But SC'll Do, Too --------------------------------------------------------------- "Monochrome Monotony: Gimme GUI, But SC'll Do, Too": Seems like that should have ended with "my darling", doesn't it? It must be the influence my two and three year-old boys are having on me. But don't you sometimes wish you could get away with talking like that to the boss? "See my eyes, boss. See them bulge. Big bulges, burning. Why, you ask? See screen. Green screen. Lots of little green letters. Fuzzy-wuzzy gween scween fulla widdle wetters... " You could sure use a new terminal. It just so happens that you're already on the list for some new hardware. In short order, a brand-new PC arrives, amber monochrome monitor and all. It soothes the eyes somewhat, but you quickly learn that amber really means dull orange. Not much better than green, really. It is, after all, still just one color. If only you hadn't walked by that obscure cubical where all the really neat stuff goes on. Full living color! Screens that were visually pleasing, with different colors to distinguish various areas, and a function bar, to boot! That guy must have the latest Graphical-User-Interface (GUI) software out there. You join in what is becoming a popular 'GreGUIan' chant: "GUI! GUI! Gimme GUI!" Only he spins around and says "GUI schmooey!" (He must have little kids, too). "Heck, this is just good ol' level 34 MAPPER. I just haven't had time to figure out this Screen Control (SC) command until just recently." He shows you a system he's working on, with color screens connected by function key bars in such a way as to instill the feeling you were playing a musical instrument, rather than running an application... The truth of the matter is that MAPPER has had the ability to create sophisticated color screens for years. It's just that the @OUT function's five-to-one technique was, to be nice, a bit awkward. Also, don't forget that the reserved word FKEY$ wasn't always around, and, until level 34, didn't support function keys above four. Not to mention the fact that nobody had color monitors, much less graphics, anyway. We all had good old UTS/20s/30s/400s, and even an occasional /200 way back when. Forget reverse video, much less color. It was easy to get into the habit of coding all screens with a simple straight-forward, nothing fancy @OUT function. I have to admit to a near fanatical obsession with the old UTS/20 keyboard. It just played so well. But the green glow did get a bit old after a while. Enter the PC. Who came up with which keys were important for what? Certainly not MAPPERites. Talk about awkward! Two and three-key toggles boggles the fingers, not to mention the mind. I wanted my /20 back with a passion. But we learn to live with what we have. Besides, emulators were new toys yet to be dismantled. Once you get into the PC world, you quickly succumb to "software madness". There are so many public domain programs that you could spend years trying everything out. "Gimme gimme! What'cha got?" Unfortunately, some of it is absolutely boring dribble, suitable for putting insomniacs to sleep. Occasionally something really neat crawls out, with an elegance of design and clarity of thought that convinces you inter-galactic aliens have been writing code for years on this very planet. One must have a color monitor to fully appreciate these jewels. Let me be the first to suggest the color wave at your site, if it hasn't already started. I'm sure that numerous studies have been conducted proving the claim that color is worth a lot more than every penny spent on it. As a colleague of mine once said: "Hey! Anthropology 101! Human beings are color creatures." So true. You wouldn't listen to the same song all the time. Why look at the same color. Boring! Boring is bad. Boring is an eye strain. Gives you headaches. Slows you down. Non-productivity. Sick leave. Wasted time and money. And it adds up. The extra cost of a color monitor over monochrome is probably recovered within the first few months of operation through enhanced productivity and reduced job stress. In MAPPER, emulating a UTS/40 allows control of color parameters at the PC level, which must be set up in the emulator's configuration. There are various attributes for fields on a screen, including: protected or not; high or low intensity; forward or reverse video; blinking or not; visible or not; strike-through; field separators, and more. It's a bit tedious to set up and doesn't give a true representation of MAPPER's color capabilities. UTS/60 emulation conforms to color attributes defined by the run designer when creating a screen either via the 5-to-1 @OUT or the @SC function. It is possible to control the color and field attributes of each character position on the screen, giving you tremendous control over the visual display. I prefer UTS/60 emulation for that reason. I've been using SC since it became available, but only in the format where commands are given in a string without the need for a rid to read and interpret. It is especially useful for displaying error messages, even though @DSM (Display Message) is designed for that purpose. DSM requires that the message be located in a rid, which includes the overhead of read I/O, and can be even more costly if the rid is created by the run. Then the Control-Page (CP) capabilities of SC struck me. You know those file-transfer runs supplied by certain emulator companies, using that famous undocumented run function output-to-video (@OTV)? SC has all the capabilities of OTV, but one SC command string can replace numerous OTV's, and there are quite a few. It was late May, 1990, and the promise of Level 35 was looming. Since the basis of the new "look-and-feel" is SC, it seemed wise to start coding screens with it. The next system I developed would be my first shot at it. Turned out it was a rather large federally mandated Welfare reform system. Oh, well. Coding SC screens by hand (no screen generating run in Level 34!) was initially tedious. The OUT function called to me repeatedly, but SC is the wave: I had to ride it. What really helped was developing a skeleton screen and then simply modifying it as necessary. Figure 1 demonstrates a basic screen design that can be used to develop entire systems. ---------------------------------------------------------------- FIGURE 1 -------- @BRK . PREP;DEF,1,PR,RV,WHI/RED;DEF,2,PR,CYA/BLU;DEF,3,AI,TS,WHI/MAG ATT,1;FLD,3,3,20,76,,2;PC,2,34;''SCREEN TITLE'' PC,10,28;''Input Field ['';FLD,,,,10,,3;PC,,-1;] PC,+2,28;''Input Field ['';FLD,,,,10,,3;PC,,-1;] PC,22,35;''Transmit ['';FLD,,,,1,,3;PC,,-1;] PC,24,1;ATT,PR;1;ATT,2;''Funky1 '';ATT,PR;2;ATT,2;''Funky2 '' ATT,PR;3;ATT,2;''Funky3 '';ATT,PR;4;ATT,2;''Funky4 '' ATT,PR;5;ATT,2;''Funky5 '';ATT,PR;6;ATT,2;''Funky6 '' ATT,PR;7;ATT,2;''Funky7 '';ATT,PR;8;ATT,2;''Funky8 '' ATT,PR;9;ATT,2;''Funky9 '';ATT,PR;10;ATT,2;''Fnky10 '';TAB @BRK KEY SC,-0 '' . @IF FKEY$ > 0,(5) ;CHG INPUT$ V1H10,V2H10 . @. PROCESS THE DATA HERE & GTO SOMEWHERE... @5:IF FKEY$ = 1 RUN ... ;IF FKEY$ = 2 RUN ... ;. @etc... ;REL . --------------------------------------------------------------- First we BRK to clear the output area. The first command (PREP) clears the screen and sets up default attributes of protected, white on black, starting on row 2, column 1 of the screen. The semi-colon separates commands. The next three commands (DEF) define sets of attributes that can be invoked by number. The first DEF says: protected, reverse video, white letters on a red background; DEF number two is protected, normal video, cyan letters on blue; and DEF number three is any input, tab stop, white letters on magenta. The next line starts with setting the screen to defined attribute one (ATT,1), creating a red screen. The FLD command creates a field, starting on row 3, column 3, 20 rows down and 76 columns wide, with attributes set by the second DEF. This creates the screen interior, now surrounded by a red border. Then we position the cursor (PC) to row 2, column 34, following it with the literal value 'SCREEN TITLE'. Then we position the cursor at row 10, column 28 to insert the literal 'Input field ['. The brackets ([ and ]) are simply to visually identify where the field starts and stops. This is for terminals that don't support color or reverse video, but still need a way to distinguish fields (we still have some 20s and 400s around). The next FLD command creates an input field, with attributes identified by DEF number three. Another field is created 2 lines below the first. Then we position the cursor at line 22, column 34 in order to create a place to transmit. Starting with "PC,24,1", we begin to create the famous function key bar. First, we position the cursor on row 24, column 1, and set attributes to DEF number two. Attributes are switched to protected (PR) only, and by default will be black. The number 1 is then inserted. Switching the attributes to DEF 2, we then create a colored rectangle in which we insert the literal "Funky1 ". The space is required to separate each piece of the bar. Then we simply repeat the process of flipping attributes and inserting text until we have a complete function bar. And finally, the TAB will put the cursor in the first field, ready for your input. Break the output area and then SC the result. The double-ticks look tacky, but they're required. Now you can either enter data or press a function key, and the pseudo-code below the SC will handle either case. This is a very simple screen, but gives a foundation upon which many screens can be based. For a smaller screen, just change the row and column where the fields start and how many rows/columns it contains. You may want to use two FLD commands to create the border and screen interior. Try different color combinations and intensities. Not all colors are compatible, and some combinations are down-right distressing. Experiment! The more you look at SC, the more intriguing it becomes. And there is certainly a lot to it. Definitely read the manual a few times. It may take a few passes across the visual receptors to sink in fully. So if you get tired of waiting for Level 35 like I did, at least you can simulate some of the new "look and feel". GUIs may be great for some things, but they're not always the best solution. You pay for them. Response will naturally be slower. No matter how fast computers get, they'll always be faster at character manipulation than graphics. I'm sure that most applications could easily live without a GUI forever. And what a lot of people associate with the 'GUI' look are just color areas on a screen, a function bar, an occasional graph or two, and maybe a 3-D shadowing effect - all of which can be done with level 34 MAPPER. By the way, if you happen to be breezing on over to Chicago for the Spring, '91 USE, INC. conference, look me up or drop a note at the Unisys World booth. Hope I see you there! ----------------------------------------------------------------- Rob Haeuser has over 18 years of Data Processing experience. He was MAPPER Coordinator and Run Designer for the Texas Department of Human Services for ten years, and is now an independent contractor working in the Austin area. Covering MAPPER topics ranging from technical to tacky, his never-ending quest is for truth, justice, and the MAPPER way.