Vern, Guy, et al, >Send your comments, wants, etc., to this list - he's listening - seriously. Does the command prompter fall in the realm of CL enhancement requests? There is one feature which I believe would have to be trivial to implement, but would really extend the usability of choice programs. What I'd dearly love to do is have the choice program be able to provide its own interface -- say a windowed lookup to a database -- then when the user selects an entry be able to pass back a parameter value for the keyword without ever seeing the typical parameter prompt screen. Currently, choice programs work well for short lists of dynamic data, but have a major annoyance for larger dynamic data. Since I always have windowed lookup subfile programs for other HLL programs to call to let a user find a say a customer or product number, it was very easy to make a choice program which does the following: - For request type C, simply return a string including "..., F4=Prompt" - For request type P, prior to returning the text to display on the next panel, I first call my windowed subfile lookup and allow them to position / sort the file select an entry. The problem is, at that stage my choice program knows exactly what value the keyword should get, but there is no way for me to pass it back to the command prompter. Instead, I have to insert the selected key into a string to pass back as the choice text, where it then gets displayed to the user but they have to rekey it on the regular prompt panel. What I'd like to propose is the ability to have the choice program signify it has already handled the user interface or otherwise determined the desired parameter value, and just pass that back to the command prompt directly. My suggestion, in order to retain backward compatibility and not require a new parameter to choice programs, would be to allow a choice program to change the request code byte of "P" to something else -- say R for Return -- and then have the command prompter treat the second choice pgm parameter as an actual keyword value instead of a list of values to display to the user. This would allow us to easily "extend" the command prompter to provide whatever keyword prompt is appropriate, and it shouldn't break any existing code. Nor should it take a long time to document in however many languages the manuals are in these days. The command prompter is one of the often under-utilized strengths of the system, yet it hasn't seen much change since early CPF days, other than POPs added in V1R2 (as I recall the timeframe). Just my .02, Doug
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.