Re: ON KEY in CONSTRUCT

>From: alex@lucas.MREC.AR (Maria Alejandra Perez Weiss) >Subject: ON KEY in CONSTRUCT >To: informix-list@rmy.emory.edu (Lista de informix) >Date: Thu, 16 Sep 93 16:55:31 ARG >X-Informix-List-Id: <list.2822> > >I've just found a weird behaviour of the CONSTRUCT statement. > >I tried to use ON KEY in order to call a help function and modify >the input buffer with DISPLAY. >(That's exactly what the manual suggests to do) >But ... >a) if the called function has an INPUT statement, the > DISPLAY shows the new value and it is inmediately cleared! > (and the buffer is empty again) >b) if the called function has no INPUT statements, it works > fine: DISPLAY shows the value and it IS in the buffer. >c) if the function has no input statement, but it's called > AFTER a function with input, it works like a) instead of b) >d) everything works ok if I compile it with c4gl instead of > generating p-code with fglpc > >Ideas ? Magic solutions ? Any wizard out there ? I guess I should answer this. However, as usual, I must point out that these comments have no official standing. 1. I refer you to the detailed, nit-picking paragraphs on page S-97 in the 4.10 I4GL Supplement S-97 where it says: Each field in a form has only one field buffer, and a buffer cannot be used by two different statements simultaneously. If a CONSTRUCT statement calls a function that includes an INPUT, INPUT ARRAY, or CONSTRUCT statement, and both statements use the same form, you may [sic] overwrite one or more of hte field buffers. When you use fields in a CONSTRUCT statement, you should not reuse them in an INPUT, INPUT ARRAY, or other CONSTRUCT statement until the first CONSTRUCT statement finishes. If you plan to display the same form more than one time and will access the form fields, you should open a new window and display a second copy of the form. 4GL allocates a separate set of buffers to each form, and you can be certain that your program is retrieving the correct field values. 2. I also refer you to the other detailed nit-picking paragraphs on page S-117 in the 4.10 I4GL Supplement S-117 where it says: Each field in a form has only one field buffer, and a buffer cannot be used by two different statements simultaneously. [followed by the same second paragraph as above] 3. COMMENTARY * The restriction described in the Supplement is not enforced, and the behaviour obtained is erratic, as described above. * The paragraphs omit DISPLAY ARRAY -- I would include it in the prohibitions above, as it too is an interactive statement (even though its name suggests otherwise). PROMPT does not use forms and so it is exempt from these considerations. * The comments are omitted from the INPUT ARRAY and DISPLAY ARRAY sections, but should be interpreted as applying, though in general it is far less likely that you'd be mucking with multiple uses of the same array. * I believe that the comment is saying that if you need to use the same form fields twice, you should: Either - Open a new window with the same form file Or - Open the same form file with a new form name - Display the new form name before re-using the fields In the latter case, it is not clear how to restore the first form, but it is a reasonably safe bet that closing the second instance of the form and redisplaying the original form and the data thereon should work. * There are bugs in this area. In general, opening a new window is the safest approach. 4. POSSIBLE INTERPRETATION * Recursive input is not at the moment supportable. In general, you will find it fails. * It is not clear whether recursive input is supported. I don't think it is, and would use the paragraphs above as primary justifications for this view. However, I'm not sure that I'm winning this argument internally. * It will pay you to study the release notes in the 4.12 release of I4GL with great care. This is one of a number of issues which will be described in nauseating detail. You'd also do well to pay attention to the 4.11 release notes. * No decisions have been made yet, but the issue is "live". * For RECURSIVE input, I predict one of two outcomes: either recursive input will be supported, or attempts to do so will be detected and reported as an error. * For arbitrarily NESTED input using a single form, the options are less clear, but either it will be supported with independent field buffers for independent statements, or it will be detected and reported as an error, or it will continue to behave as it does at the moment -- erratically. * In any release prior to 4.12, I guarantee that in general (but not in all circumstances), the code will fail. Sometimes it will simply misbehave; sometimes it will dump core. I also predict that there are various people out there with applications that mostly work most of the time despite all this. My only comment is: "You're EXTREMELY lucky!" Things could (probably will) change before 4.12 is shipped. The erratic behaviour of previous versions won't change. Yours, Jonathan Leffler (johnl@informix.com) #include <disclaimer.h>