Re: Prompt Service Program.

My apologies. Sometime I believe you will know what I'm talking about.


Let's say on one screen there's a field called STORE. Press F4 on the
field, it will call a procedure StorePrompt in the Prompt service program.
Lets say the the screen also has Status. Press F4 to call a procedure
called StatusPrompt.

/free
store = StorePrompt();
status = StatusPrompt();
/end-free

Both prompts would display a list in a window.


Would you suggest putting these in the same service program called
PROMPTS? StorePrompt and StatusPrompt are not related to each other than
they are both fields where you can press F4 and display a list. Or would
you suggest against service programs all together and just use RPG
sub-proprgram calls?

What if I eventually have 150 procedures that could use any number of
different files.



On Mon, Apr 16, 2012 at 3:27 PM, Booth Martin <booth@xxxxxxxxxxxx> wrote:

What I have done is to make a dropdown box for certain fields and have
it field & file specific. I also made the program a maintenance program
for that field if the program is called without parms.

http://www.martinvt.com/Subfiles/Dropdown_Box/dropdown_box.html

This is a skinnied down example that I put together for demo purposes.

This isn't exactly what you asked for, but it might have a few useful
ideas for you. It is mouse enabled or F4, and has a mouse enabled
scrollbar. (I love scrollbars on subfiles!)



On 4/16/2012 2:17 PM, Kurt Anderson wrote:

Are you talking about a prompt being something like a user is on a

screen in an 'action' field and they want to press F4 to see the values
(and select one)?

A quick brainstorm on the topic:
Program calls service program procedure to bring up a prompt window.

Pass in the program name, screen name, and field name.

Service program will reference a table where you have all of the

possible prompt values stored along with their descriptions (A , Add; D,
Delete; etc).

Service program pops up a window (or screen, whatever) for user to

select from the options.

Service program procedure returns the selected value. To prepare to

handle most situations, you could return an 80a field and if you're on IBM
i 7.1 you can code RTNPARM on the Procedure Interface so it returns the
selection by reference.

If this method would work, there's really no growth for added prompts

since they'd all be stored in a table. That table might look like this:

Header table:
Program
Screen
Field
Header1a
Header1b (in case you want to stack header descriptions to save on

horizontal space)

Header2a
Header2b (in case you want to stack header descriptions to save on

horizontal space)

Max Value Length

Detail Table
Program
Screen
FieldValue
Description

The service program could then dynamically build the screen. I think I

did something like this a long time ago and at that time I made the value
max size 20 and then the description a certain size so the only dynamic
part was the wording that appeared on the screen (not the actual positions
of values).

-Kurt

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:

rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Michael Schutte

Sent: Monday, April 16, 2012 1:40 PM
To: RPG programming on the IBM i / System i
Subject: Prompt Service Program.

Would any advise for or against putting any new prompt procedures in the

same service program? Just curious. I started a new service program with
the intent to put any new prompt programs in this service program. But
then I got to thinking maybe that would be a bad idea because as the size
of the service program grew, so would the amount of memory each time the
program was activated. I am using a named activation group.

Anyway, am I off on trying to create just one service program for any

prompt-able field?

--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing

list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,

visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at

http://archive.midrange.com/rpg400-l.

--
Booth Martin
802-461-5349
http://www.martinvt.com
--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.