× 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.



Dennis Lovelady wrote:
rob@xxxxxxxxx wrote:
Sort of like a "select (put fields here) from table"
and your prompt has to get the name of the fields?
And it is not enough that they get display the list
of fields, they have to be able to put a one in front
>> of 1 or more fields to return desired fields?

Is the item after the comma your requested enhancement
and you have the rest done?

JHHL wrote:

Completely blank slate. Just a concept at this point. Would
apply to potentially at least two system commands.

If you are looking for functional (how it looks to the user) recommendations, I'd model the UI after STRSQL's SELECT prompt.
If you type SELECT in an SQL session, the press F4, you'll have
a screen of fields for which F4 is valid.


Sure would be nice if the prompting interface enabled a program as interface to provide the selection algorithm to actually fill the prompts. Seems daft that it just enables an interface to list the elements as "choices" via the CHOICEPGM; i.e. not actually select from what is presented in the list. That such a feature was lacking, is one of the first things I commented on when I first started creating commands. I wondered, "Where is the 'choosing' in a CHOICEPGM, if there is no selection enabled?" Merely showing me what I could type in myself, or copy\paste of what is presented, was hardly what I had expected. But that is really just a deficiency with the parameter prompting in general, because the single value or special values [from literals in the PARM & ELEM source], aside from the specific values generated in the choice-list, should also be selectable.

FWiW if the prompted values are something that would complete the command, consider the CRTTBL SRCFILE(*PROMPT) as an example for which the special\single value *PROMPT is the final value on the parameter. Pressing Enter or F16 proceeds into the CPP which then presents a panel for the prompted interface, in response to the *PROMPT requested on the parameter. The create [sequence\translate] table extended prompting uses F6=Create to complete\exit. I suppose that multiple *PROMPT values could effect navigating multiple list\selection panels, optionally forcing the user to proceed through each sequentially, or by activating a more navigable interactive prompted interface.

For a "system command" I would think making a private copy of the command would be the best approach. The custom command would add a prompting feature [e.g. special value *PROMPT] to the desired parameter(s) and its POP [or was it the CPP ?] could re-invoke the prompted command with the additional values that have been [generated from the UI as selection panel and since] inserted into the [now modified] command string; eventually with all values resolved\selected, the full\actual system command string issued via QCMDEXC or QCAPCMD. I stopped dealing with command objects so many years ago I do not really recall the tricks for the re-prompting a command to enhance its function, but Simon had long ago posted some examples on midrange somewhere [I did not try to query the archives].

?CUSTOM/CPYF FROMFILE(named) FROMKEY(*PROMPT)

Regards, Chuck

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.