Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!dimacs.rutgers.edu!seismo!uunet!zephyr.ens.tek.com!tektronix!sequent!lugnut
From: lugnut@sequent.UUCP (Don Bolton)
Newsgroups: comp.databases
Subject: Re: Need help w/Informix 4gl forms
Message-ID: <53440@sequent.UUCP>
Date: 18 Feb 91 18:14:54 GMT
References: <1991Feb12.220516.242@investor.pgh.pa.us> <53027@sequent.UUCP> <985@trac2000.ueci.com> <1991Feb15.174329.8722@informix.com>
Reply-To: lugnut@sequent.UUCP (Don Bolton)
Distribution: usa
Organization: Sequent Computer Systems, Inc
Lines: 50

In article <1991Feb15.174329.8722@informix.com> davek@informix.com (David Kosenko) writes:
>In article <985@trac2000.ueci.com> gls@trac2000.ueci.com (Gary Smith) writes:
>>> In article <1991Feb12.220516.242@investor.pgh.pa.us> 
>	bwm@investor.pgh.pa.us (Bruce Miller #307) writes:
>>> >I am working with Informix 4gl v.1.10.00 and need some help with screen
>>> >forms.  What I would like to do is to call a screen form using a program
>>> >variable rather than calling the form directly.
>>
>>Another way would be to pass the form name on the command line and
>>when you enter the program get the argument i.e:
>>				LET pawnbroker = ARG_VAL(1)
>>Then prepare a statement like
>>		LET exec_str = "OPEN FORM pawn_form FROM '", pawnbroker, "'"
>>		PREPARE prep_form from exec_str
>>		EXECUTE prep_form
>>And then you can use form pawn_form as a normal form, as if you opened it
>>with constants.  Any statement can be made that way.
>
>	Unfortunately, that is not the case (that any statement can be prepared
>that way), and in fact this very statement is one of the types that cannot
>be prepared.
>	As stated in the INFORMIX-4GL 4.0 Reference Manal Volume 2, page 7-190
>(page 7-178 in the 2.10 version) the syntax for the PREPARE statement is:
>
>	PREPARE statement-id FROM string-spec
>
>Note 3 on this statement reads:
>
>	The string-spec cannot include any of the following statements:
>	CLOSE, DECLARE, EXECUTE, FETCH, LOAD, OPEN, PREPARE, UNLOAD, and
>	WHENEVER.
>
>Dave

This limitation becomes frustrating when moving multiple modules from
a developement to a production locale. I could "kill" for being able
to set up *all* relative application PATH information in *ONE* place,
(like GLOBALS). So much else in 4gl lets one do global set up and sub-
sequent refrencing, that it seems to make sense it should be able to
do the same for refrencing a PATH structure....

	"I gave it a thumbs down" Siskal      
	"I agree with him" Ebert
	"I wet my pants" Rex Reed

Don "everyone's a critic" Bolton

Of course the opinions either expressed or implied therein are genuine
lugfodder [tm] and likely bear no resemblence to the opinions of any
said rational beings, and likely not my employer either.