FIND mode not working

[Joe Boyle]

Just one more thought, what happens if you make T-WORK, T-SAFI and TCOMPUTER
all reset at startup/mode.

Regards, Joe.

-----Original Message-----
From: powerh-l-bounces+atla38=dsl.pipex.com at lists.sowder.com
[mailto:powerh-l-bounces+atla38=dsl.pipex.com at lists.sowder.com] On Behalf Of
Syed Shahul Hameed Mustaffa
Sent: 21 July 2005 22:44
To: Deskin, Bob
Cc: powerh-l at lists.sowder.com
Subject: Re: FIND mode not working

Dear Bob,

I believe I tried this dummy PATH procedure and it didn't seem to work
(I'll try again). You may be right about REQUEST verbs not setting
thing in request buffer. Because, the cursor does not prompt at the
REQUEST fields as long as there is no PATH procedure or even with a
dummy PATH procedure. However, when I moved the internal procedure
GETPARAMS to the PATH procedure, the cursor prompts at the REQUEST
fields when i choose FIND mode.

Regards,
SYED.



On 7/21/05, Deskin, Bob <Bob.Deskin at cognos.com> wrote:
> Did this code work on MPE/iX as is (with the INTERNAL procedure in the
FIND)? This will generate a default PATH procedure but there won't be any
prompting because of the ACCESS statement on the PRIMARY. I still don't
understand why you need the internal procedure in the FIND and not in the
PATH.
> 
> Of the top I don't know why it won't work. It may be that the REQUEST
verbs aren't setting things in the request buffer unless they're in the PATH
procedure. I suggest coding a dummy PATH procedure that says:
> 
> PROCEDURE PATH
>  LET PATH = 1
> 
> just to override the default. Not sure if it will help, but it won't hurt.
> 
> I would also suggest (as I believe someone suggested before) that you add
RESET AT STARTUP to your temps that are used in retrieval. These may get
reset for every retrieval cycle.
> 
> Bob
> 
> 
> -----Original Message-----
> From: Syed Shahul Hameed Mustaffa [mailto:sshahulgm at gmail.com]
> Sent: July 21, 2005 10:35 AM
> To: Deskin, Bob
> Cc: powerh-l at lists.sowder.com
> Subject: Re: FIND mode not working
> 
> 
> Dear Bob,
> 
> I'm working on AXIANT 4GL.
> I've attached the code file.
> This is the original MPE/IX code.
> 
> Some explanation.
> SW-TYPE can be S or W.
> IF I enter S for SW-TYPE, then the screen should accept a value for
> field T-SAFI.
> IF I enter W for SW-TYPE, then the screen should accept a value for
> field T-WORK.
> IF I enter the value for T-SAFI, CHECK-SAFI internal procedure finds
> the value for T-WORK and TCOMPUTER thru the internal procedure
> If I enter the value for T-WORK, CHECK-WORK internal procedure finds
> the value for T-SAFI and TCOMPUTER.
> 
> As it is this code does not work in AXIANT.
> I had to move the 'DO GETPARMS' procedure to the PATH procedure to
> make the screen accept the SELECT MODE. The rest I have explained
> already in my earlier mail.
> 
> Thank you.
> Syed
> 
> On 7/21/05, Deskin, Bob <Bob.Deskin at cognos.com> wrote:
> > I've come into this late so if something here has already been
mentioned, my apologies.
> >
> > Your code would help because we don't know what you've done with the
PATH procedure.
> >
> > By default, QDESIGN generates a PATH procedure to request index segment
values and a FIND procedure to do the retrieval based on the values entered.
If you look at a default PATH procedure you'll see that based on the entered
values, the PATH item is set. PATH is then used to determine which of many
possible retrieval methods is used in the FIND procedure.
> >
> > In Select mode, there is an additional step between the PATH and FIND
procedures where QUICK prompts for selection values. There is an optional
SELECT procedure that you can code but it's normally not needed.
> >
> > When you enter F or S in the action field, QUICK executes the PATH
procedure (and does selection if you entered S) and if the PATH procedure is
successful, continues on to the FIND procedure to retrieve data. If the PATH
procedure issues an error, things stop there.
> >
> > Putting REQUEST verbs in the FIND procedure is actually too late. The
REQUEST verb is special in that it prompts for the data in the field buffer
but also puts the value in a special request buffer to be used for the
retrieval. This is because it is possible to change the values originally
prompted for. So a save area is needed for subsequent retrieval.
> >
> > The way QUICK is designed to work is to establish your retrieval path in
the PATH procedure and the do the retrieval in the FIND procedure.
> >
> > By the way, have you used the QUICK debug trace to see what's happening
with the data you've entered.
> >
> > Regards
> >
> > Bob
> >
> > -----Original Message-----
> > From: powerh-l-bounces+bob.deskin=cognos.com at lists.sowder.com
> > [mailto:powerh-l-bounces+bob.deskin=cognos.com at lists.sowder.com]On
> > Behalf Of Syed Shahul Hameed Mustaffa
> > Sent: July 21, 2005 4:48 AM
> > To: Joe Boyle
> > Cc: powerh-l at lists.sowder.com
> > Subject: Re: FIND mode not working
> >
> >
> > Dear Joe,
> >
> > I cannot remove the existing FIND procedure. There are application
> > logic built into it.
> > I am explaining the scenario in a better fashion underneath. I'm
> > trying as much not to confuse. If u still require the code (which is
> > simple), I'll post it.
> >
> > In the original code, the FIND procedure calls an internal procedure
> > called GETPARAMS.
> > This procedure contains the REQUEST statements. Based on what I enter
> > on the REQUEST fields, a temporary variable called TCOMPUTER is set to
> > a value.
> >
> > With this code, when i execute the screen and try to select FIND mode,
> > it does not work. However when, I moved the GETPARAMS procedure to the
> > PATH procedure, I can get the screen in select mode. I can enter the
> > parameters and everything seems to be ok. But the problem starts when
> > I hit the ENTER Key to initiate the data retrieval. The TCOMPUTER
> > value set by the PATH procedure gets lost (reset to 0) when the
> > control reaches the FIND procedure. In the find procedure, I have a
> > GET statement that uses this TCOMPUTER to search for records. I tried
> > hardcoding the TCOMPUTER value that I lose on the transit, and the
> > search works fine. I searced in vain for any intermediate code that
> > resets the value of TCOMPUTER.
> >
> > Pls. give me some insight about what happens between PATH and FIND
> > procedure calls.
> >
> > Thankyou somuch.
> > Syed
> >
> >
> > On 7/20/05, Joe Boyle <atla38 at dsl.pipex.com> wrote:
> > > Hi Syed,
> > >
> > > You don't give any details of the access syntax you have coded against
the
> > > table so it is difficult to suggest much.
> > >
> > > Try clicking on the path icon to create one; incidentally why do you
think
> > > that there isn't one and have you coded your own find procedure ?
> > >
> > > As for the 'list detail' equivalent, you have to turn (or it is easier
if
> > > you turn on) 'keep temp files' in the build profile. You then add
syntax
> > > like ' set list sql list transaction detail procedures' into the set
> > > statement of the screens identity tab. You then commit the repository
and
> > > then recompile the screen.  I believe that the procedural code will
then be
> > > found in the .qkr file in the build location.
> > >
> > > Regards, Joe.
> > >
> > >
> > > -----Original Message-----
> > > From: powerh-l-bounces+atla38=dsl.pipex.com at lists.sowder.com
> > > [mailto:powerh-l-bounces+atla38=dsl.pipex.com at lists.sowder.com] On
Behalf Of
> > > Syed Shahul Hameed Mustaffa
> > > Sent: 20 July 2005 15:37
> > > To: Joe Boyle
> > > Cc: powerh-l at lists.sowder.com
> > > Subject: FIND mode not working
> > >
> > > Dear Joe,
> > >
> > >  In a screen I have a FIND procedure. However the FIND mode is not
working.
> > > I found that there is no PATH procedure. Have you encountered such a
> > > scenario?
> > >
> > > Dear Gurus,
> > >
> > > If there is anyone who has encountered this scenario, pls help.
> > >
> > > Regards,
> > > SYED.
> > >
> > > --
> > > = = = = = = = = = = = = = = = = = = = = = = = = = = = =
> > > Mailing list: powerh-l at lists.sowder.com
> > > Subscribe: "subscribe" in message body to
powerh-l-request at lists.sowder.com
> > > Unsubscribe: "unsubscribe &lt;password&gt;" in message body to
> > > powerh-l-request at lists.sowder.com
> > > http://lists.sowder.com/mailman/listinfo/powerh-l
> > > This list is closed, thus to post to the list you must be a
subscriber.
> > >
> > >
> >
> > --
> > = = = = = = = = = = = = = = = = = = = = = = = = = = = =
> > Mailing list: powerh-l at lists.sowder.com
> > Subscribe: "subscribe" in message body to
powerh-l-request at lists.sowder.com
> > Unsubscribe: "unsubscribe &lt;password&gt;" in message body to
powerh-l-request at lists.sowder.com
> > http://lists.sowder.com/mailman/listinfo/powerh-l
> > This list is closed, thus to post to the list you must be a subscriber.
> >
> >       This message may contain privileged and/or confidential
information.  If you have received this e-mail in error or are not the
intended recipient, you may not use, copy, disseminate or distribute it; do
not open any attachments, delete it immediately from your system and notify
the sender promptly by e-mail that you have done so.  Thank you.
> >
> >
> >
>

-- 
= = = = = = = = = = = = = = = = = = = = = = = = = = = =
Mailing list: powerh-l at lists.sowder.com
Subscribe: "subscribe" in message body to powerh-l-request at lists.sowder.com
Unsubscribe: "unsubscribe &lt;password&gt;" in message body to
powerh-l-request at lists.sowder.com
http://lists.sowder.com/mailman/listinfo/powerh-l
This list is closed, thus to post to the list you must be a subscriber.