Re: 4GL form won't fit on a screen

Path: emory!sol.ctr.columbia.edu!hamblin.math.byu.edu!hellgate.utah.edu!cs.utexas.edu!sdd.hp.com!think.com!rpi!ispd-newsserver!kodak!static!amiano From: amiano@static.Kodak.Com (Mitch Amiano) Newsgroups: comp.databases.informix Message-ID: <1991Oct8.172301.1038@kodak.kodak.com> Date: 8 Oct 91 17:23:01 GMT References: <1991Oct2.233348.27406@vexcel.com> Sender: amiano@static (Mitch Amiano) Organization: Eastman Kodak Co., Rochester, NY In article <1991Oct2.233348.27406@vexcel.com>, alanb@vexcel.com (Alan Baxter) writes: |> |> I want to use a screen form in 4GL for manipulating reseau calibration |> reports in a photogrammetric database. The problem is that a reasonably |> formatted form won't fit on one screen. |> |> What's a good way to handle this? It doesn't look like the screen array |> was designed for the case where one row won't fit on a screen. Should I |> distribute the calibration values over multiple screens and have the |> user use a menu to move between screens? Is there a better or more |> standard way to handle this? |> |> I'd appreciate any suggestions. Send e-mail if it's convenient and I'll |> post the solution if anybody's interested. |> |> The table definition follows: |> ------------------------------------------------------------------------------ |> $create table reseau_cal_rep |> ( |> rcr_key serial, |> rcr_pn char(20), |> rcr_date char(20), |> rcr_exp_coef float, |> rcr_cal_temp float, |> rcr_pt1_x float, rcr_pt1_y float, |> . |> . |> . |> rcr_pt64_x float, rcr_pt64_y float |> ); Some others have suggested using multiple functions, windows, and inputs to gather the fields. I heartilly agree that this is your only option, however you may choose to implement it. I4gl simply doesn't handle input of large structures without some extra programmer navigation. Consider, however, the work involved in maintaining consistency with the rest of the Informix application. Question: Do you CARE if it is consistent with the normal i4gl INPUT ARRAY interface ? If only you are using it, you may choose to be less elegant with the user interface, to avoid the extra coding required. If not, then the extra work MAY be worth it. The ideas posted so far have been on the right track, to the effect of simulating one large INPUT ARRAY with a number of smaller INPUT ARRAY functions. This approach will work, and will require a bunch of code to implement. As a suggestion: try looking at the array sideways. Most of us would initially code a form something like this: [rcr_key][rcr_pn][rcr_date][rcr_exp_coef][rcr_cal_temp][rcr_pt1_x][rcr_pt1_y]..... [rcr_key][rcr_pn][rcr_date][rcr_exp_coef][rcr_cal_temp][rcr_pt1_x][rcr_pt1_y]..... [rcr_key][rcr_pn][rcr_date][rcr_exp_coef][rcr_cal_temp][rcr_pt1_x][rcr_pt1_y]..... [rcr_key][rcr_pn][rcr_date][rcr_exp_coef][rcr_cal_temp][rcr_pt1_x][rcr_pt1_y]..... [rcr_key][rcr_pn][rcr_date][rcr_exp_coef][rcr_cal_temp][rcr_pt1_x][rcr_pt1_y]..... [rcr_key][rcr_pn][rcr_date][rcr_exp_coef][rcr_cal_temp][rcr_pt1_x][rcr_pt1_y]..... [rcr_key][rcr_pn][rcr_date][rcr_exp_coef][rcr_cal_temp][rcr_pt1_x][rcr_pt1_y]..... with other screens/windows popping up when the cursor enters rcr_pt1_y, or when F-key is hit. If take the shared part of the key out of the array, and move it sideways, you might have: Key: [rcr_key] [rcr_pn] [rcr_pn] [rcr_pn] [rcr_date] [rcr_date] [rcr_date] [rcr_exp_coef] [rcr_exp_coef] [rcr_exp_coef] [rcr_cal_temp] [rcr_cal_temp] [rcr_cal_temp] [rcr_pt1_x] [rcr_pt1_x] [rcr_pt1_x] [rcr_pt1_y] [rcr_pt1_y] [rcr_pt1_y] [rcr_pt2_x] [rcr_pt2_x] [rcr_pt2_x] [rcr_pt2_y] [rcr_pt2_y] [rcr_pt2_y] [rcr_pt3_x] [rcr_pt3_x] [rcr_pt3_x] [rcr_pt3_y] [rcr_pt3_y] [rcr_pt3_y] [rcr_pt4_x] [rcr_pt4_x] [rcr_pt4_x] [rcr_pt4_y] [rcr_pt4_y] [rcr_pt4_y] ..... ..... ..... with screens comming into view with an AFTER FIELD rcr_pt4_y clause and/or a page down/page up F-key combination. Seperate input array functions would still be required, but it is a different way of looking at it, and may give you more room on screen. IMAO, simulating the row-insert/row-delete, ACCEPT, INTERRUPT, and other like operations together as one integrated interface is non trivial, but it can be done, and sometimes the time spent is actually worth it.