Now, I'll ask the idiot's question: Is this the sort of thing that API's or MI coding would resolve well? Is there a way through those methods to read keystrokes? -----Original Message----- From: email@example.com [mailto:firstname.lastname@example.org] Sent: Friday, November 12, 1999 12:19 AM To: email@example.com Subject: Re: new display file features James, >IMHO, one of the failures of OV/400 was the performance degradation when >you had too many people choking the system with keystroke activity. I surprising amount of that processing was done by the WS controller itself, not the OV programs. To enable OV, the WS controllers for the S/36 and AS/400 added a whole new mode and set of data streams. When a program (such as OV) would enable "word processing" mode in the controller (instead of the normal "data processing" mode), it also sends a series of data streams which load tables in the WS controller with the text for various error state messages and Fx key prompt texts, as well as numerous display stream orders defining portions of the screen, the scale line, audit window, etc. (Among other things this let them handle multiple languages for the prompts, and make changes via PTFs instead of being part of the WS controller hardware.) Unlike a normal DP mode program, when you pressed an AID key, the WS controller handled much of the work and required zero cycles from the program in main storage. The WS controller also automatically displayed text in the "audit window" based on what character the cursor was placed under. (These texts were also downloaded to the controller at start-up.) So although it may appear that the OV program is processing keystroke level activity, it really wasn't near as much as you may think. The controller was performing lots of it without taking any resources from the main processor. Can you set word processing mode yourself? Sure, if you send the right data streams. But WP mode cannot co-exist with DP mode on the screen at the same time, and regular input field orders are not accepted by the controller while a screen is in WP mode. So it would be a royal pain to implement. And it wouldn't help anyway. There still is no data stream order I can find that tells the WS controller to send each keystroke back as it happens, even in WP mode. Only AID keys that the controller can't handle by itself return control to the program. Here is how I think this would have to be implemented on the AS/400: 1) Define your screen like normal, with a regular "position to" field 2) Display the format using WRITE, not EXFMT, and DFRWRT(*NO) 3) Start a loop in your code which issues either a READ IMMEDIATE or a READ MODIFIED IMMEDIATE ALTERNATE data stream command. This lets you get the current contents of all input fields, or only those with MDT set, without regard to whether an AID key has been pressed. 4) When the input field changes, reposition/refill your subfile and WRITE it again, putting the cursor at the current address 5) Check if an AID byte is pending; if not return to step 3 6) Issue READ to resume normal operations Step 3 can be accomplished either using UDDS and the USRDFN keyword, or by using the Dynamic Screen Manager API's QsnReadImm or QsnReadMDTImmAlt. Using QsnReadImm would be easier since you would get a consistent input buffer feedback for the format. Step 5 has me wondering. There has got to be an easy way to just test if the WS controller has locked the keyboard following an AID key press and is ready for one of the read commands. But I don't see one offhand in the 5250 data streams or the DSM API's. So the only thing I can think of to avoid the AID wait inherent with the read commands is to make the DSPF have a WAITRCD() value of *IMMED or 1 second or whatever. Then code the same way you would for displays which auto time-out. Issue the RPG READ operation and if an error occurs check the INFDS to make sure it was a time-out. If it timed out then no AID was available so return to step 3. By using a WAITRCD() of 1-2 seconds, you would at least be yielding some processor time. This process may work great for a lightly loaded system, or if only a couple of users are in this loop at any given time. But I'd hate to think of what it would mean it was used regularly. That's part of the appeal of client/server. Let an intelligent WS handle the user interface, and the 400 handle the back end. Doug +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: firstname.lastname@example.org +---
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.