Re: new display file features

[dhandy@xxxxxxxxxxx (Douglas Handy)]

Booth,

>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?

Not in the same manner as on a PC.  On a PC, each keystroke generates
a hardware "interrupt" which WinDoze can turn into a message or
"event" to notify your program of the keystroke.  (Actually, there is
a separate interrupt for pressing the key down, and for releasing it.)

This makes it easy for a program to attach an "event handler" to
process keystrokes.  The program doesn't need to be in a loop looking
for keystrokes, it just waits to be notified of them.

On the 400, there are similar interrupts but they stop at the WS
controller, which is what processes the keystrokes.  Not even MI or
UDDS or DSM can tell the controller to trigger an event or notify your
program of each keystroke, AFAIK.

There is something which you can do, which I described towards the end
of my last message.  In theory I think it would work, but I haven't
tried it.  And I'm concerned about the overhead it would create.

Although you can't be notified of each keystroke, a program can read
the contents of input fields (or the whole screen) at any time without
the need for an AID key to be pressed first.  These so-called Read
Immediate commands take the data directly from the WS controller's
format tables, and are accurate to the last keystroke.  (Which is how
stuff like Peek Plus can do its thing.) 

So if you code a loop, you can continuously read the input fields and
detect each change.  But I don't think it is something you'd want to
be doing on a multi-user machine.

There is also a way to make it check only every x seconds, so the
program wouldn't be quite as resource intensive but would still
respond without the need for an AID key.

Cutting out the OV stuff from my last message, I ended with:

>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: david@midrange.com
+---