On Saturday, 95/12/23, Murray Lesser wrote to David Noon about "Pl/i
Query" as follows:

ML> it right before.  Would have tried the .CV2 version except I am even
ML> less sure about PL/I HANDLEs than I am about PL/I pointers, at this
ML> stage in the learning process.

Hi Murray,

There's nothing mysterious about HANDLEs. They are simply pointers
"bound" to a specific type of data item or aggregate, just like
pointers in C/C++.

ML>     My friend may have been right, but I would remind you that
ML> PKBDKEYINFO is an "output" parameter, and is passed back to the
ML> program by the KBD16CHARIN API.  Following my previous approach as
ML> modified by my friend's advice, this would have been a pointer
ML> declared BYADDR SEGMENTED, somehow related to the KBDKEYINFO
ML> structure.

I think you are a victim of doc-speak here. What the documentation
should have said is that the KBDKEYINFO structure is the output
parameter and the PKBDKEYINFO is the means by which the API obtains
access to it. Thus, passing the KBDKEYINFO using BYADDR synthesises
the 16:16 pointer for you, as you seem to have discovered.

ML>     If I had been calling a KBD API in C, I would have passed
ML> &KBDKEYINFO as the first parameter and would have used the
ML> almost-undocumented (PVOID)DosSelToFlat() to thunk the output back
ML> to a 32-bit pointer.  But PL/I doesn't seem to need that API

If you compile with the LIST option to give you the assembler code,
you will see that the compiler makes a call to DosFlatToSel() to
convert the 0:32 pointer to 16:16; the C Set ++ compiler does the same
thing. Likewise, if you use a PTR SEGMENTED in 32-bit code it calls
DosSelToFlat() "automagically" for you.

ML>     I changed the approach completely.  This one works as advertised! No
ML> pointers explicitly declared, segmented or otherwise!  Cribbed the

Yes, looking at your code you have done it the "clean" way by saying
what your calling program is going to pass to the subroutine, rather
than just "send this address across". Well done!

ML> I worried about whether the approach would work with a call to a
ML> 16-bit API function, but it seems to (minimal testing so far).  PL/I
ML> appears to handle all the thunking required without my interfering. 

Indeed, that's what an "industrial strength" language should do for
you.

ML> Haven't bothered yet to add the SELECT required to report function
ML> keys, etc., but will (when I am sure it works) for another program
ML> I'm writing.  Any comments would be appreciated.

Try this for an expanded version of your KBDKEYINFO type.

     DEFINE STRUCTURE
          1    KBDKEYINFO,
               2    chChar              CHAR(1),
               2    chScan              CHAR(1),
               2    fbStatus,
                    3    Interim_char        BIT(1),
                    3    Final_char          BIT(1),
                    3    Immediate_conv_req  BIT(1),
                    3    *                   BIT(3),
                    3    Extended_key_code   BIT(1),
                    3    Shift_status_only   BIT(1),
               2    *                   BIT(8), /* bNlsShift */
               2    ShiftKeyStat,
                    3    SysReq_down         BIT(1),
                    3    CapsLock_down       BIT(1),
                    3    NumLock_down        BIT(1),
                    3    ScrollLock_down     BIT(1),
                    3    Right_Alt_down      BIT(1),
                    3    Right_Ctl_down      BIT(1),
                    3    Left_Alt_down       BIT(1),
                    3    Left_Ctl_down       BIT(1),
                    3    Insert_on           BIT(1),
                    3    CapsLock_on         BIT(1),
                    3    NumLock_on          BIT(1),
                    3    ScrollLock_on       BIT(1),
                    3    Either_Alt_down     BIT(1),
                    3    Either_Ctl_down     BIT(1),
                    3    Right_Shift_down    BIT(1),
                    3    Left_Shift_down     BIT(1),
               2    KeyTime             TYPE ULONG UNAL;

This will allow you to address the individual flag bits by means of
mnemonic names, rather than masking them with bitwise "ands" the way
you would in C.

ML>     In the meantime, thanks for the help (it got me thinking again), and
ML> have a happy holiday season.

Same to you Murray.

Regards

Dave


 * KWQ/2 1.2i * If you need MS Bob, you deserve Windows 95!
--- Maximus/2 3.00