Re: Forms problem

mike,

[Quoted] thanks very much for that idea.

i've not tried it as yet, but just from reading, am i right in saying that the use of "next_record" (as opposed to matts "go_record") will result in the search for the correct record being rather slow and also visible to the user on screen. this may not be a problem for a handfull of records, but if the desired row was say 150 rows from the first record then it might be more of a problem.

i may be wrong about this, it's just that i've used "next-record" in the past and had the aforementioned problems then.

let me know what you think.

duval.

In article <Lkp65.106$Pl2.47213_at_wdc-read-01.qwest.net>,   "Mike Dwyer" <dwyermj_at_co,larimer.co.us> wrote:
> Nice solution, Matt. May I suggest another but similar one for deval?
>
> Create a text item in the control_block, name it 'something_ROWID'.
> (Reference the query datablock.)
>
> In the query block, create this KEY-ENTQRY trigger:
> :control_block.something_rowid := :something.rowid;
> enter_query;
>
> In the query block, create this KEY-EXEQRY trigger:
> if :control_block.something_rowid is null then
> :control_block.something_rowid := :something.rowid;
> end if;
> execute_query;
> while :something.rowid <> :control_block.something_rowid
> and :system.last_record = 'FALSE' loop
> next_record;
> end loop;
> if :something.rowid <> :control_block.something_rowid then
> first_record;
> end if;
> :control_block.something_rowid := null;
>
> By saving the rowid instead of the block position, you will always
 return to
> the same database row, even if the re-query returns a different
 result. If
> the original row is not in the new result set, you will remain on
 record #1.
>
> - Mike
>
> "Matt B." <mcb_at_fightspam.sd.znet.com> wrote in message
> news:sliqkmukjev32_at_corp.supernews.com...
> > "deval" <japs1_at_my-deja.com> wrote in message
> > news:8jbdj1$5s4$1_at_nnrp1.deja.com...
> > > I am using Forms 4.5 and was wondering if there is a way to re-
 query a
> > > multi-row, tabular block without losing the place of the cursor.
> > >
> > > If the user is on say the 100th row in the block, and hits
 the "re-
> > > query" button (which is just an EXECUTE_QUERY) the focus moves to
 the
> > > first record in the block. This is not the desired result, i'd
 rather
> > > the cursor stayed on the record the user was on before just
 before the
> > > re-query was hit.
> > >
> > > Does anyone have any solutions to this problem???
> > >
> > > Is there a better way of achieving what I am trying to do?
> >
> > Easy. Create a control block item (not in the same block) and on
 KEY-EXEQRY of
> > the queryable block (but before the block clears), populate that
 control
 item
> > with the record number:
> >
> > :CONTROL_BLOCK.REC_NUM := :SYSTEM.CURSOR_RECORD;
> >
> > On PRE-QUERY of the queryable block, reset a counter variable
 (you'll see
 why
> > you'll need this in a moment)
> >
> > :CONTROL_BLOCK.RECORDS_FETCHED := 0;
> >
> > Track the new records via POST-QUERY (you'll see why in a moment)
 of the
> > queryable block:
> >
> > :CONTROL_BLOCK.RECORDS_FETCHED := CONTROL_BLOCK.RECORDS_FETCHED + 1;
> >
> > Then, after the actual EXECUTE_QUERY call in KEY-EXEQRY, move the
 user
 there:
> >
> > SYNCHRONIZE;
> > IF :SYSTEM.MODE = 'NORMAL' AND
> > :CONTROL_BLOCK.RECORDS_FETCHED >= :CONTROL_BLOCK.REC_NUM AND
> > :SYSTEM.CURSOR_RECORD != :CONTROL_BLOCK.REC_NUM THEN
> > GO_RECORD(:CONTROL_BLOCK.REC_NUM);
> > IF FORM_SUCCESS THEN
> > :CONTROL_BLOCK.REC_NUM = 1;
> > :CONTROL_BLOCK.RECORDS_FETCHED := 0;
> > ELSE
> > RAISE_FORM_TRIGGER_FAILURE;
> > END IF;
> > END IF;
> >
> > I think :SYSTEM.MODE = 'NORMAL' is what you want to evaluate (you
 want
> > POST-QUERY to finish firing before you do the moving). I remember
 there's
> > 'NORMAL','ENTER-QUERY', and there's one other status IIRC that
 represents
 the
> > "working" state (while the query is processing). Check the online
 help
 for the
> > SYSTEM.MODE variable - I can't remember offhand what that third
 status is.
> >
> > -Matt
> >
> >
>
>

Sent via Deja.com http://www.deja.com/
Before you buy. Received on Wed Jun 28 2000 - 00:00:00 CEST