|
Sorry I forgot -- My point about the program message queue is that when you
specify MYPROGRAM and zero, you are sending the messages to the PEP, not to
the main procedure. This is why I think I wrote the dopey "find the name of
the main procedure" procedure in the first place. Still -- it only worked
for interactive apps and I found myself limited (and regretting it) later.
Stu
On Thu, Mar 11, 2010 at 17:21, Stuart Rowe<rowestu@xxxxxxxxx> wrote:
The program message queue displayed by the message subfiles is the one
attached to the 2nd procedure in your program. Your programs begins with a
PEP, then the main procedure. It's the main procedure you want to target.
If you want to hard-code the message-sending proc, pass the name of this
main procedure in the call stack qualifier. This would only be good for a
one-off rush job and I don't recommend this approach.
I wrote once a procedure to determine the name of the main procedure, it
was clunky but it worked. It used the Retrieve Call Stack api and looked
through it until the top of the program-related call stack entry was found
and then forward one stack entry to find the actual name of the main
procedure (it is not always the same name as the program object, and in the
case of a service program it is never that name).
Those two approaches are really only good for sending message to
interactive screens. Period.
Lately (well last 8 years or so) I write all my procedures such that they
"percolate" messages backward when messages are expected. So your message
proc would always just send the message to *, call stack count 2 (1 backward
past my caller, or my caller's caller). Each procedure, in turn, contains
code to propagate those messages backward using Move Program Messages API
and the Resend Escape Message API until they get to some proc that wants to
stop the process and display the messages -- in your case, probably the main
procedure where your display file code is. This is the most workable, and
traceable, method I know of.
On Thu, Mar 11, 2010 at 14:41, Robert Rogerson<rogersonra@xxxxxxxxx>wrote:
Thanks John,
I did look at your example and changed my program accordingly.
I changed the Call Stack Entry = 'MYPROGRAM' and Call Stack Counter = 0.
When I ran the program no message was displayed. When I ran the program
in
debug it definately sent the message but nothing appeared on the screen.
This is the approach I'm trying to achieve (not having to specify the Call
Stack Counter for each procedure I'm in) but I'm still unable to
accomplish
it.
Do you have any insight?
Thanks,
Rob
On Thu, Mar 11, 2010 at 2:13 PM, John McKay<jmckay@xxxxxxxxxxxxxxxx>
wrote:
At www.rpglanguage.com/message_subfile I have an example of what Ithink
youlist
are looking for. All the parameters, except for message id and message
queue, are defaulted and the QMHSNDPM is stored in a procedure z_sndmsg.
You can contact me directly for more clarification.
Regards,
John McKay mba
----- Original Message -----
From: "Robert Rogerson"<rogersonra@xxxxxxxxx>
To:<RPG400-L@xxxxxxxxxxxx>
Sent: Thursday, March 11, 2010 6:07 PM
Subject: Displaying a message using QmhSndPm...
I don’t quite understand the Call Stack Entry and Call Stack Counter
combination.
What I have currently, and working, is as follows:
Mainline
QmhSndPm( ‘XXX9999’ : ‘QCPFMSG *LIBL’ : sndData : %Len(sndData) :
‘*INFO’ : ‘*’ : 1 : sndMsgKey : errorCode);
Process1();
In Process1 I have
QmhSndPm( ‘XXX9999’ : ‘QCPFMSG *LIBL’ : sndData : %Len(sndData) :
‘*INFO’ : ‘*’ : 2 : sndMsgKey : errorCode);
Process2();
In Process2 I have
QmhSndPm( ‘XXX9999’ : ‘QCPFMSG *LIBL’ : sndData : %Len(sndData) :
‘*INFO’ : ‘*’ : 3 : sndMsgKey : errorCode);
So as it stands all three messages are sent to the display as expected.
I would like to create a procedure called SendMessage with one parameter
messageId (Char 7).
Is this possible and if so what should be the values of the Call Stack
Entry
and Call Stack Counter combination?
Thanks,
Rob
--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing
To post a message email: RPG400-L@xxxxxxxxxxxxlist
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
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.
As an Amazon Associate we earn from qualifying purchases.
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.