From: mdchaney@fractal.ucs.indiana.edu (M Darrin Chaney)
Subject: Re: Dynamic FRS
Organization: Indiana University, Bloomington
Date: Tue, 18 Aug 1992 18:23:46 GMT

In article <xyz> sfc@tpghq.com (Steve Caswell) writes:
>
>From: ron@sigyn.cs.athabascau.ca (Ron Haukenfrers)
>Newsgroups: comp.databases.ingres
>Subject: Dynamic FRS
>
>>Does anyone know of a way to dynamically create a field in an ingres form?
>>I would like to create a field at runtime because it's datatype, length
>>and attributes are all derived at runtime.  I guess I can use the old
>>hack of creating a big text field and doing the manual type conversions,
>>but that doesn't solve the problem of data length and attributes.
>>
>INGRES does not provide a way to do this.  It does give you a way for your
>application to determine what fields reside on a form and build dynamic FRS
>statements to manipulate the form.  The only way I know of to create a field
>on a form dynamically is to monkey around with the ii_field system catalog,
>which would be VERY messy.

This comes up with enough regularity that I'll give up and respond.  It is
possible, and not too difficult.  The way that I do it involves using an
embedded language with C.  In order to do it with ABF, the ii_field catalog
would have to be used.  With C, you have more control.

When a form is compiled, a huge data structure is created.  When you use the
addform statement, the data areas are "malloc'ed", and the form is created.
Before the addform, the forms system has no knowledge of the form, so you
can play around with it all you want.  Note that with compiled forms, the
forms system catalogs are never checked.  If you don't believe that, write
an ESQL/C or EQUEL/C program that does nothing but forms statements.  You'll
find that you can run the program without connecting to a database, or even
running a database server.

The secret to doing dynamic forms stuff is in
$II_SYSTEM/ingres/files/frame61.h.  It's the include file that has the
typedefs for the various forms objects.  It's not commented, but a day
or two of hacking and you can have the relevant parts decoded.

At any rate, it's ugly business, and could change at any release (although
I don't think that's likely).  However, it's really not that difficult to do
something simple.  For instance, let's say that you have a field that might
need to be a different datatype.

Simply create a field for all possible datatypes that you might need, and make
them invisible.  Before the addform, determine which one you need.  Find the
matching field (by searching through the form structure), and change its
name and x,y coordinates to place it in the right place.

If you need something more like QBF, you'll probably end up creating the
entire form def yourself, which isn't so easy.  For what I believe most
people want/need, simply creating a form and changing a few field
attributes isn't too difficult.

If you'd like, I have made available a sample application which does just
about everything imaginable to a form.  It's on fractal.ucs.indiana.edu,
in the anonymous ftp account.  Check out /pub/ingres/dynforms.  I may
submit a paper to the next Ingres World on the subject, but I'm not
sure if it's of general interest.  I also have a half-commented version of
frame61.h, but that's copyrighted material.  Maybe the diffs would be
appropriate?

If it is of interest to you, do me a favor and drop me an email message just
stating that it is.  Don't post such, please.  I would like to get an idea
of how many people want this.

	Darrin
-- 

mdchaney@iubacs mdchaney@bronze.ucs.indiana.edu mdchaney@rose.ucs.indiana.edu

"It's a marvel of vegetable containment..."