RE: Re[2]: From classical 4gl to Dynamic 4gl
Posted in 1998
Topics: Connectivity: ESQL/C, 4GL & Embedded SQL, Platform-Specific Issues
If you have access to old 4Js manuals version 1.02.1b there is a section on fgl_setsize on page V-41. There is an awful lot in the old 4Js manuals - its just finding it... Jon > ---------- > From: Jonathan Leffler[SMTP:jleffler@informix.com] > Sent: 28 August 1998 01:19 > To: Ramesh.Ramamurthy@alltel.com > Cc: Sadagopan; Sathish; informix-list@iiug.org > Subject: Re: Re[2]: From classical 4gl to Dynamic 4gl > > On Thu, 27 Aug 1998 Ramesh.Ramamurthy@alltel.com wrote: > > > The two things that come to my mind is ANSI C and redesigning the > > screens. The Eval copy that we gat from informix contained only > ANSI > > C compatible Header files. > > That is certainly a documented restriction. With the production copy, > you > generally get a copy of GCC which is (obviously) ANSI C aware. I'm > not sure > about the demo version. > > > We have to redesign the screen due to the reason that the charecter > > based screens to not take advantage of all the features that an gui > > can give you. One limitation that I found was a big anoyance is > that > > the screen size is limited to 80X24 > > Hmm... There's an undocumented function (or, at least, there's a > function > for which I haven't found any documentation), which helps here: > > MAIN > ... > --# CALL fgl_setsize(rows, cols) > --# CALL fgl_init4js() > ... > END MAIN > > I found an example of its use in some sample code I was looking at. > Note > that it is invoked before you call the initialization routine! I > haven't > checked what happens if you call it elsewhere. > > > I hope informix does something about this. The reason why this > > software has this limitation is because of backward compatibility to > > CHARECTER based. I consider this an invalid argument since the > whole > > reason why somebody buys this software is GUI. > > > D4GL is a very deciplined software. It will not cut any slack for > bad > > programming practice. This is in a way good because 4GL is so > > forgiving that your software has too many memory leaks. > > Certainly, if you have sloppy I4GL code, especially with regard to the > number > of arguments to and return values from called functions, you will > quickly find > out about your mistakes. This was always true of I4GL-RDS; it is > generally > true of D4GL. > > One other item to beware of is that with a 6.00 or later ESQL/C, the > cursor > names are global rather than local to a single source file. This can > cause > chaos if you reuse cursor names indiscriminately. > > > ________________________ Reply Separator > > Subject: RE: From classical 4gl to Dynamic 4gl > > Author: "Sadagopan; Sathish" <sadagop0458@att.com> at internet > > Date: 8/26/98 2:54 PM > > > > Hi Ramesh, > > Any pointers when migrating 4GL applications to D4GL ? > > TIA > > Sathish Sadagopan > > > > > ---------- > > > From: Ramesh.Ramamurthy@alltel.com > > > Sent: Wednesday, August 26, 1998 10:15 AM > > > To: Sujit.Pal@alltel.com; informix-list@iiug.org; > akormancik@intec.sk > > > Subject: Re: From classical 4gl to Dynamic 4gl > > > > > > I just completed compile and doing a demo of D4GL to the big guys > in > > > my company. Our product has the same description as your product. > > > The conversion was not, in my experience, much of a problem it is > > > just a routine grunt work and is only on the C side of the > product. > > > For the code that we had the output is very good. We didn't have > > > much trouble, there was trouble here and there and other than that > > > it went pretty smooth. Don't have too much expectation because > you > > > will have all the limitations that 4GL imposes in D4GL, like your > > > window can only be 80*24. In order to come over this problem I > > > decided just to redesign the screens which is lot more easier than > > > moving to some other language and building this product from > ground > > > up. We are actually going to build new screens for a customer > with > > > this product and see there reaction since they are the people who > > > are going to pay for it. > > > > > > Ramesh > > > > > > PS: There are a few gotcha's in the compilers. Always this ANSI > and > > > it will help. For more information feel free to send me a mail. > > > > > > ______________________________ Reply Separator > ______________________________ > > > Subject: From classical 4gl to Dynamic 4gl > > > Author: Sujit Pal at ATNEDEN1 > > > Date: 8/26/98 8:18 AM > > > > > > Ramesh > > > > > > You want to take this? If you do, reply to Anton's email > below and to > > > informix-list@iiug.org > > > > > > Sujit > > > > > > ________________________ Forward Header > > > Subject: From classical 4gl to Dynamic 4gl > > > Author: Anton Kormancik <akormancik@intec.sk> at internet > > > Date: 8/26/98 10:59 AM > > > > > > We work and develop under 4gl for 6 years. Now I am very > interested > > > in Dynamic 4gl but haven't seen that and have no experience with > it > > > yet. Did anybody of you recompile his 4gl programs to Dynamic > 4gl? > > > If yes, then let me please know what were your biggest problems at > > > changing from terminal applicatians to windows applications? It > > > seems very hopeful but I very would like to know about possible > > > problems. > > Yours, > Jonathan Leffler (jleffler@informix.com) #include <witticism.h> > Guardian of DBD::Informix v0.60 -- http://www.perl.com/CPAN > Informix IDN for D4GL & Linux -- http://www.informix.com/idn >