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