Re: choicepgm question

Hi, Tim:

Chuck is correct -- the "choice program" is very limited in what it can do. For example, when you press F4, it should let you pick from a list, using the cursor or a mouse, but it does not; so you just have to type in (or cut-and-paste) what you see there.

You might also investigate creating a "prompt override program" -- with a PMTOVRPGM, you can control what values are shown as defaults whenever a user prompts a command.

Let me know if you would like to see some examples of a PMTOVRPGM, or some examples showing how you could use a CHOICEPGM, even though they are rather limited.

All the best,

Mark S. Waterbury

> On 12/16/2015 5:56 PM, CRPence wrote:

On 16-Dec-2015 15:57 -0600, tim wrote:

I added a dynamic choice selection using choicepgm keyword.

My question is, can I pass a value to the choicepgm?

for example, I am prompting for state. If I enter "N" in the state
field then hit F4, I would like to pass the N to the choicepgm so
that I only list states beginning with N.

What I recall about the Choice Program (CHOICEPGM) feature, was that the feature was way too limited, and was mostly just a replacement for the default capabilities of choices; i.e. effectively just a list of literal values, with no capabilities, not even to select from that list :-( And one of those limitations, is that the data typed or defaulted on the parameter, is not passed to the ChoicePgm; the program is expected to just list every possible value; similarly there is no access to the other parameter values, for example if there was a Dependency (DEP) definition that limited the _valid_ choices that could be made, there is nothing passed for that either.

So other than what could be found elsewhere [than what is passed-in], e.g. the request message in the program message queue of the request processor call stack entry, there is not much upon which the coded ChoicePgm can base decisions for limiting the output. I recall there are capabilities to read data for the last active format written to the display, but the prompter IIRC uses the dynamic screen APIs ¿dsXXX or snXXX? [hmm, I can not recall the naming] rather than an actual Display File (DSPF) with a Record Format (RCDFMT) so finding the data input might not be as conspicuous; though the Record Format List is stripped from system-supplied DSPF anyhow, so maybe that path would not be so easy either.

The old OfficeVision used to use something like STATE(*PROMPT) that would simply effect the Command Processing Program (CPP) invoking a pre-processor that presented a more robust screen interaction with the user, before continuing; i.e. the user presses Enter to continue, so as to select the State after Command Prompting, whereupon the interaction could include the typical Subset or Position-to and actual 1=Select capabilities, even to include the possibility of selecting multiple entries at which the standard prompting is quite deficient. Of course that [essentially, logically] limited the capabilities to interactive if the default is *PROMPT, or outside interactive that Special Value defaults to something other than what is implied, so the value by name is misleading when not prompting; though now with newer Command Exit feature(s), that default I presume could be modified, making the parameter value change to the actual value.

I am not sure if Simon had discussed CHOICEPGM in the past, but sometimes he had creative ideas using Command (CMD) capabilities; effectively fruitless, but funny, a web search turned up my mentioning the same possibility in the past [http://archive.midrange.com/midrange-l/201002/msg00816.html] along with my "wondering" about "choice". But without Simon as a keyword, there is the following thread I did not read, among a few others with that kwd: [http://archive.midrange.com/midrange-l/200310/threads.html#01019]
[https://www.google.com/search?q=%22choicepgm%22+site%3Aarchive.midrange.com]