Re: 4gl mods

Here are some comments on the list of suggested modifications to I4GL posted by Jonathan Leffler: FORMS / WINDOWS - I4GL-F01: Built-in support for multi-screen forms. Is this a forms issue or a windowing issue? I think more the latter, for I would like to see automatic window control extend to all input and display statements. One way to implement this would be to extend the syntax of the CURRENT WINDOW statement to allow: CURRENT WINDOW IS { window-name | SCREEN | AUTOMATIC } If the AUTOMATIC keyword was used, window control would be automatic (of course) as described below. Otherwise it would be the same as it is now. Under automatic window control, I4GL would bind the window name to all screen records in a form that was opened in that window. Then, whenever a screen field was referenced implicitly or explicitly in a CONSTRUCT or INPUT statment, the field's window would be popped forward if it wasn't already visible. In automatic window mode, I4GL would allow DISPLAY to partially or completely hidden windows. If a window was only partially hidden, the viewable portion of the window would be updated on the screen. If the window was subsequently brought forward, the data DISPLAYed to the window while it was in the background would be shown. This behavior is closer to most of today's generic windowing environments than Informix's current method. With this facility, the programmer could forget about stacking, tiling and all of that mess. This would get rid of a big chunk of code for our site. REPORTS - I4GL-R04: Multiple concurrent invocations of a single report. One way to implement this might be to extend the START REPORT syntax to: START REPORT report_name [...] [AS alias_name] Then all other report-oriented statments such as OUTPUT TO and FINISH would refer to the alias name for that instance of the report. I don't have a need for this facility so much as I need the ability to to have several different reports STARTed at the same time and be able to guarantee the order in which they are sent to standard output. I do all of this now with temp output ASCII files, but I'd much rather be able to say something like: START REPORT report_name [...] DEFERRED to have the report generated but held in a temp file by Informix. The report would be sent to its destination when it was FINISHed. The FINISH statement could also be enhanced so that the report destination could be specified after it was generated, as in: START REPORT report_name DEFERRED [...] FINISH REPORT report_name [TO {file_name | PRINTER | PIPE program}] That is, the FINISH statement would have the same options as the current START statement. PROMPT - I4GL-P01,2,3 The list entries requesting enhancements to PROMPT could probably be collapsed into one request that the statement be enhanced to provide as much of the functionality of INPUT as makes sense. Also, PROMPT currently uses the same input controls as screen forms if the screen has been cleared or a form is in use. Otherwise, it uses sort of a "cooked" input method. My personal preference would be for PROMPT to always use "canonical" input. This would still have to be under Informix's control to be able to process special keys, etc. CONSTRUCT - I4GL-C01: Reinstate AUTONEXT in CONSTRUCT. If AUTONEXT is in fact reinstated in CONSTRUCT, I would want to be able to control whether AUTONEXT was recognized during CONSTRUCT separately from INPUT. In other words, I would want to be able to have a form with AUTONEXT fields that did AUTONEXT during INPUT, but defaulted to not do AUTONEXT during CONSTRUCT. I could turn on that feature with an OPTION or some such statement. CONSTRUCT - Embedded SQL during QBF input It would be handy to have some generic way to be able to input free-form SQL query text during a CONSTRUCT statement. You can hack it up now, but it's kind of clunky. 3GL FEATURES I'd like to have some way to checksum a record's contents, and/or be able to access a record with fields of certain types as if the fields were of different types -- like C UNIONS or Fortran labeled COMMON. This is kind of esoteric, but I have had requirements for it in the past. If anyone has questions or comments about any of the above, feel free to e-mail me, or post if more appropriate. I also have some questions about what will be done with the list, but I'll save those for a separate message. Thanks, Walt. -- Walt Hultgren Internet: walt@rmy.emory.edu (IP 128.140.8.1) Emory University UUCP: {...,gatech,rutgers,uunet}!emory!rmy!walt 954 Gatewood Road, NE BITNET: walt@EMORY Atlanta, GA 30329 USA Voice: +1 404 727 0648