Re: 4GL windows display problem

Path: emory!wupost!zaphod.mps.ohio-state.edu!malgudi.oar.net!sunc.osc.edu!cis.ohio-state.edu!rutgers!pyrnj!pyramid!infmx!johnl From: johnl@informix.com (Jonathan Leffler) Newsgroups: comp.databases.informix Message-ID: <1991Nov13.173125.10719@informix.com> Date: 13 Nov 91 17:31:25 GMT References: <1991Nov13.072027.18891@wvus.org> Sender: Jonathan Leffler (johnl@informix.com) Organization: Informix Software, Inc. In article <1991Nov13.072027.18891@wvus.org> George wrote: >I'm currently in the process of building what seems to be a rather complex >application in Informix 4GL (4.0). I have a wide table, approximately 60 >fields, where it's impossible to fit all the fields into a single screen >of display. > >The way that I'm going about doing this is doing an "input by name" for the >fields of the first window, then following the last field of the first win- >dow, doing "after field ... call input2()", where "input2" is a second win- >dow with its own "input by name" for a second block of variables. After the >last vairable of input2, I call input3, opening window #3, and likewise, at >the end. with window #4 > >"Input by name" works fine, but where I'm making a query, I'm having problems. >Namely, in the case of where I've made a query, and then want to see the >results of my query for the variables in windows #2, #3, or #4. I have a menu >command called "Screen" which calls a function called "change_window", which >subsequently executes a "current window is", naming the appropriate window. > >In program execution, it all works as it's supposed to, displaying the re- >quested window, and the various screen variables, but as soon as that >happens, the screen is re-painted with window #1, regardless of which has >been named by "current window" (except if window #1 is requested as the >current screen, then there's no re-paint). The traces I've put in (I don't >have the debugger) tell me that the re-paint is happening following completion >of the code associated with my "Screen" menu command, when program control >is returned to the menu statement. > >I should also note that my forms being used are built so that they take up the >entire allowed available space on the screen. Also, I'm opening my windows >with "open window ... with form at ...", rather than opening my window and >form searately, and doing a "display form". > >What am I missing here? How do I solve this problem? The way I work similar programs is: 1. There is a menu window at the top of the screen. There is a second window used for I/O at the bottom of the screen. 2. The I/O functions set the I/O window as the current window. The menu function sets the menu window as the current window. 3. The I/O functions also keep track of which form is currently displayed in the I/O window. 4. Rather than have nested input functions, I use a loop which looks something like: WHILE TRUE CASE WHEN io_form = 1 LET io_form = in1_function() WHEN io_form = 2 LET io_form = in2_function() WHEN io_form = 3 LET io_form = in3_function() OTHERWISE EXIT WHILE END CASE END WHILE You will need to design the logic which detects interrupts and ACCEPT. 5. Each of the inX_functions handles input for the particluar screen form. 6. There is a diX_function for each input function which displays the relevant data to its own screen form. The display function ensures that the correct form is displayed. 7. Your screen option code simply ensures that the relevant screen is current by setting the current form in the I/O window (by calling diX_function). 8. You need some quite complex logic and state tracking if you are going to achieve the seamless scroll from top of window N to the bottom of window N-1 when the user goes backwards. It is easiest, I think, if you have INPUT WRAP on -- though if someone comes up with the logic for this with no INPUT WRAP, I'll be happy to see if it is simpler. 9. You will need to organise your code so that you can check whether all fields which should not be null have non-null values, because you cannot tell which screen the user will hit the ACCEPT key in. This code needs to jump back to the relevant field with a suitable message. Good luck with your logic, -- ------------------------------------------------------------------- Jonathan Leffler (johnl@informix.com) #include <disclaimer.h>