Re: Does anybody know the real story on 4GL/GX?
Posted in 1993
->From: phillips@analyst.win.net (Charles Phillips) ->Subject: Re: Does anybody know the real story on 4GL/GX? ->Date: Tue, 14 Sep 1993 14:16:11 GMT ->Reply-To: phillips@analyst.win.net (Charles Phillips) -> ->Clay, how much re-coding did you have to do with GX? And why is ->it so slow - I didn't think there was any emulation taking place. -> ->Charles Phillips ->phillips@analyst.win.net ->> ->>>We continue to hear conflicting stories from Informix on the availability of ->>>their 4GL/GX product. Does anybody have a working copy? Or has anybody gotten ->>>a straight scoop? ->> ->>I got a copy running on an RS/6000 and it is S L O W... ->>-- ->>Clay Irving N2VKG | See the happy moron ->>New York, New York | He doesn't give a damn. ->>clay@panix.com (personal) | I wish I were a moron ->>clay@garpac.com (work) | Oh God! Perhaps I am! -> My experience with evaluating 4GL/GX is about a year old, so I did not repsond before. (Who wants yesterday's news?) However, two things I found are directly related to the questions you asked, so here goes. Keep in mind that the problems I am about to describe may (or may not) have been fixed in more recent releases of GX. 1. We had to RECODE part of our application because we used large forms in large windows, i.e., more than 24 lines. Lines in GX are "taller" than lines in text mode, to allow for the graphical widgets, so we needed to reduce the total number of lines in our forms. (We reduced the number of rows in a screen array.) Your screens will have a rather different aspect ratio in GX, as compared to text mode, and it is much more noticeable in multi-line forms. I do not expect that this has been changed, but maybe. 2. GX was SLOW for two distinct reasons (at least): a. The button bars that replace ring menus worked really well, but they were repainted a LOT. Back then I counted three repaints for most actions, such as button clicks. It was even worse if you chose to operate from the keyboard, (hot-keys still worked, for example), instead of using the mouse. We reported this, so it might have been fixed. b. Scrolling a screen array was *horrendously* SLOW. When we reported this problem, the folks at Informix said we were using screen arrays in ways they did not foresee. (Why not? SCROLL is a standard 4GL command.) Anyway, they took some of our code for use in stress testing their product, so I expect that this is improved by now, if not completely fixed. Regards, Alan ___________________________ ______________________| R. Alan Popiel |__________________________ \\ Internet: | Martin Marietta, Tech Ops | / \\ alan@den.mmc.com | P.O. Box 179, M/S 5422 | Std disclaimers apply. / )Voice: | Denver, CO 80201-0179 USA | ( / 303-977-9998 |___________________________| (But you knew that!) \\ /________________________) (____________________________\\