RE: Prompt Service Program.

In my opinion (for what it's worth)
If more than one program needs to display the same list for the same field, then yes, create a procedure within a service program.
If only one program needs to display a list for a field, then create a procedure IN THAT PROGRAM. This way, if another program needs that same procedure in the future, then just lift the code from that program into a service program to be used by ALL programs where needed.

Alan Shore
Programmer/Analyst, Direct Response
E:AShore@xxxxxxxx
P:(631) 200-5019
C:(631) 880-8640
"If you're going through Hell, keep going" - Winston Churchill

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Michael Schutte
Sent: Monday, April 16, 2012 4:08 PM
To: RPG programming on the IBM i / System i
Subject: 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.

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


Disclaimer: This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. Any views or opinions presented are solely those of the author and do not necessarily represent those of the company.