[comp.databases] resuming to a new field in form.

afshin@rd-atlas.UUCP (Afshin Taheri) (08/12/89)

In my OSL code I want to have a menu item that when it is entered ,
the cursor goes to a specific field. I cannot use the "Resume field "
function because the problem is that it will resume the procedure. 
I have a submenu item inside a retrieve loop and I don't want to close 
this procedure.

Ex. of the OSL Code:
"item1" = {
formname := RETRIEVE (....
.
.
. . . . . ) WHERE ....
{
"item2" = {
    /* I like to go to a specific field following the item1 entering 
       and then the submenu item2 entering.			     */
  .  .   .  
  }
}


Afshin Taheri

Internet : rd-atlas!afshin@src.honeywell.com
UUCP     : uunet!src.honeywell.com!rd-atlas!afshin

bg0l+@andrew.cmu.edu (Bruce E. Golightly) (08/21/89)

It can't be done under Ingres 5.x. I even tried a couple of things to
fool the system, and those didn't work either.

I can't remember right off hand, but this may be one of the extensions in
version 6.

Bruce

robf@squid.rtech.com (Robert Fair) (08/22/89)

>>From: bg0l+@andrew.cmu.edu (Bruce E. Golightly)
>
>It can't be done under Ingres 5.x. I even tried a couple of things to
>fool the system, and those didn't work either.
>
The original posting Bruce is replying to hasn't reached here, but you
certainly  can move to different fields in both ESQL and 4GL, to resume to 
a new field on the form just do:

	EXEC FRS RESUME FIELD <fieldname> ;

in  ESQL, or:

	resume field <fieldname> ;

in 4GL. Similarly you can resume on a specific tablefield column using:

	EXEC FRS RESUME COLUMN <table> <column> ;
or
	resume field <table>.<column> ;

There  are other  more specialized variants like resuming on the "next" 
field/column:

	EXEC FRS RESUME NEXT;
or
	resume next;

(This is only useful in a field/column activation when  you have left a
 field and are conceptually already on your way to another field -
 INGRES checks the key entered by the user to determine what the "next" 
 field is - go forwards, backwards etc and then goes there.)

There are also things like resume on the menu, and resume at the
same place:
	EXEC FRS RESUME MENU;
	EXEC FRS RESUME ;
or:
	resume menu;
	resume ;

These all work in both INGRES 5.0 and  R6. The only tricky case is moving
to the "next" field from an frskey or menuitem activation, which is 
fairly uncommon, since generally this is trying to duplicate features the
FRS provides automatically (moving from field to field, running a block
of code on leaving a field/column etc). If the problem is a spec which
says "user will press function key 7 to move from field to field", then use a
mapfile to map the input key to the builtin FRS functions like "nextfield"
or "previousfield" and let the FRS do the work.  

In the very rare case where you want to still control tabbing using 
a menuitem and a generic "next" field, a little programming can do the 
trick (basically the INQUIRE_FRS/INQUIRE_FORMS statement lets you find out 
where you are, the RESUME statement lets you put the field/column name 
in a variable to dynamically change the field - you just provide the 
mapping from "here" to "there", which can be done several ways, from asking 
the FRS, to querying system catalogs, to defining your own sequence). All 
this can be  put in a library routine, so you just do (in ESQL):

	get_next_field(next_field);
	EXEC FRS RESUME FIELD  :next_field;

or for 4GL:

	next_field=callproc get_next_field;
	resume field :next_field;

Robert Fair
Technical Support,
Relational Technology, Inc

bg0l+@andrew.cmu.edu (Bruce E. Golightly) (08/23/89)

The comments made by Mr. Fair are certainly true. Both QUEL and SQL provide
mechanisms for controlling movement from field to field. These do not work
in the most useful fashion under certain circumstances.

Under Ingres V5, RESUME causes a RETRIEVE or SELECT loop to terminate. The
developer must, therefore, choose between the use of a select loop (with
its sub-menu) and the contorl provided by resume. This can get very interesting
if cursor movement has been attached to an FRSKey definition within the
current block of code. (This subject formed the basis for a paper I did
at the national conference in New Orleans last April.)

I don't have the release 6 doc handy, so I will refrain from comment on that.
It does stick in my mind that this one was on the hit list, though.

Bruce

jkrueger@dgis.daitc.mil (Jonathan Krueger) (08/24/89)

The following example builds and executes correctly on INGRES 5.0/04a
(vax.u43/02) and 5.0/05a (pyr.u42/04), which are the most recent releases
of INGRES that RTI sells for Berkeley UNIX on VAX and Pyramid
respectively.  It demonstrates one way to use the resume construct without
terminating a retrieve loop.  It needs a related form, database, table;
construction of them should be evident from the code.  If not, mail me and
I'll send you a shell archive with everything you need.

-- Jon

#define	NAMESIZE	20

main()
{
	startup();
	run();
	cleanup();
}

##startup()
##{
##	ingres mydb
##	forms
##	forminit myform
##}

##cleanup()
##{
##	endforms
##	exit
##}

##run()
##{
##	char	c_name[NAMESIZE + 1];

##	retrieve (c_name = mytable.mycol)
##	{
##		display myform read
##		initialize
##		{
##			putform (name = c_name)
##		}
##		activate menuitem "Next":
##		{
##			breakdisplay
##		}
##		activate menuitem "Resume"
##		{
##			resume
##		}
##		activate menuitem "Name":
##		{
##			resume field name
##		}
##		activate menuitem "Department"
##		{
##			resume field department
##		}
##		activate menuitem "Other":
##		{
##			resume next
##		}
##		activate menuitem "Menu"
##		{
##			resume menu
##		}
##	}
##}
-- 
Jonathan Krueger    jkrueger@dgis.daitc.mil   uunet!dgis!jkrueger
Isn't it interesting that the first thing you do with your
color bitmapped window system on a network is emulate an ASR33?

robf@squid.rtech.com (Robert Fair) (08/24/89)

>>From: bg0l+@andrew.cmu.edu (Bruce E. Golightly)
>
>Under Ingres V5, RESUME causes a RETRIEVE or SELECT loop to terminate. 

This is only true when you have a SELECT loop nested within a  DISPLAY loop.
Basically whenever you continue/terminate an outer loop from an inner loop the
inner loop will normally get cleaned up as well (here the RESUME continues
the DISPLAY loop, so the SELECT loop will be cleaned up).

For applications where the logic is:

	for (each row in dataset)
	do
		display data on form
		edit data
		cleanup
	done

the SELECT loop should be logically outside the form DISPLAY loop. 
This is no problem in ESQL/EQUEL, but conceptually caused difficulties in 5.0 
ABF, where an "attached select" did a SELECT loop within the DISPLAY loop for 
the current form, and then displayed a submenu for the user for each row.

This works fine for most cases, except for when you want to use RESUME in
the submenu - in 5.0  submenus were not objects that you could RESUME on, 
so doing a RESUME inside the attached select put you back at the outer DISPLAY 
loop, and cleaned up the  SELECT - all correct, but sometimes rather surprising 
for users !

This has been updated in INGRES R6 in two ways:
- The functionality of submenus has been  extended so that it is  possible to 
  RESUME in a submenu loop (i.e. a submenu is now a real {menu,form} combo 
  rather than just a simple menu with the screen still displaying the form)
  For ABF this makes "attached selects" work the way Bruce wants them to, 
  without any coding changes, while EQL has extra flexibility to work both ways.

- An explicit SELECT loop has been added to both ABF and  ESQL so you
  can directly control what happens for each data row - call a new frame, 
  perform a calculation, etc.

Robert Fair
Technical Support
Relational Technology, Inc