Re: Choice Programs

[dhandy@xxxxxxxxxxx (Douglas Handy)]

Loyd,

>The only drawback I've found so far (and I could be wrong with this) is that
>you only can code the actual values; you can't get a value and description
>(for instance, a member name and its member text).

You can do whatever you can fit within the maximum 32-byte string you
get.  So you could return 10 bytes with a member name, a blank, and
the first 21 bytes of the member description.

Or you could return twice the number entries and alternate between the
member name and the first 32 of the description.  This would look a
little like a folded  subfile.  By inserting hex attribute codes as
the first and last bytes, you could even change colors to make it more
readable, with the member name, source type, and change date on one
line and the description underneath.

The command propmpter doesn't really treat the return values as a list
of permissible responses.  It just throws them into a the equivalent
of a subfile display.  So one of the choice programs I use is for any
command parameter which accepts a date.  If they press F4, the choice
program builds a calendar display with the current month first, and
the current day highlighted via embedded display.  I can fit four
months at a time on the screen.  The first scrreen shows the current
and next month, plus the previous two months.  Paging will show the
eight months before that.

</soapbox on>

You can get creative if you think about it.  Unfortunately, there is
not a method to identify a new parameter value directly.  This would
be a great advantage.  This would let the choice program take
responsibility for displaying the choices and getting user input, then
just return the selected value back to the command panel.  My
suggestion to IBM was something like allowing us to change the first
choice program parameter from 'P' to 'V' or whatever, to signify the
second parameter is to be used as the value directly, rather than the
list of values normally returned with request type 'P'.  I think this
should be fairly trivial to implement in the command prompter, while
maintaining backward compatibility with all existing choice programs.

I like to enable F4 choice programs for database lookups too, for
example a customer number.  Why not?  I already have windowed subfile
lookup programs for calling from HLL programs.  So I just make choice
programs which are like a wrapper around the subfile lookup.  For
request type 'C', I return choice text like 'Number, F4=Prompt'.  But
for request type 'P', I first call my windowed subfile lookup program
so they have position to capability, multiple sort variants, etc, and
can just put a '1' in front of the record to select.  This then gets
returned to my choice program.  But since I can't directly pass this
back to the command prompter, it returns "Value selected was:" on the
first line and the selected value on the second.  They then have to
type the value in.  But at least they have the benefit of lookup
window, and if IBM would ever enhance the command prompter it would be
simple to change my choice program wrappers to take advantage of it.

</soapbox off>

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