× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



> From: Scott Klement
>
>      Basing each key might be more lines of code -- but then again it
> might be less.   The way you're doing it, you need to do a new set of
> MOVEs each time the screen is used.   With based keys, you only have to
> do it once at the beginning.

Scott, I don't think I was clear on what I'm doing.  These programs no
longer have display files, but I need them to think they do.  The way PSC400
works is that each I/O opcode (such as EXFMT) is replaced with a call to an
API.  One of the things this API returns is a numeric code indicating which
key was pressed by the user.  This number then needs to be mapped to the 24
command key indicators.  So, no matter what, every time I return from the
API, I need to set/reset the command key indicators based on the key
pressed.


> Furthermore, what happens if the program changes a function key?  It's
> possible to do a "SETOFF" or "SETON" of *INKx keys.   With the move
> method, you'd have to move all of the compatible keys TO the *INKC before
> displaying the screen, and move them back AFTER displaying the screen.
> This would not be necessary using pointers.

I'm not sure what this means.  With my technique, the user can still set
their *INKx indicators on and off however they want in the code, and
everything will work just fine (which would not be the case if I used the
AID byte technique).  As to your second point, *INKC is never used by a
display file, it's set as a result of the I/O operation.  Setting *INKC on
or off won't affect a display operation; display files only allow indicators
01-99 for conditioning.


> I agree that if the indicators are always contiguous that basing them as a
> group is nicer -- but personally, I wouldn't trust that method unless it's
> documented by IBM to always be contiguous...

As Barbara Morris pointed out, nothing is cast in stone, but the amount of
work the RPG ILE compiler team would have to do to make the indicators
non-contiguous is much more than the work I would have to do, so I'm
probably pretty safe.  And again, if it ever does change, I can simply
rewrite my key setting routine to use the technique I use in RPG400, which
is basically 24 separate moves.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.