4GL INPUT ARRAY: How to ask Delete[Y/N]? before deleting a row

Path: emory!att!cbnews!mvctm From: mvctm@cbnews.cb.att.com (carl.t.mosley) Newsgroups: comp.databases.informix Message-ID: <1992Jan6.153200.15031@cbnews.cb.att.com> Date: 6 Jan 92 15:32:00 GMT Organization: AT&T Bell Laboratories Using I-4GL 1.10/2.10: During an INPUT ARRAY statement, when the user presses the DELETE key, I want to ask the user to confirm the delete. It is obviously a bad idea to not do this. Even though the row is not deleted from a table, the user does not know the difference of deleting from the array or deleting from the table. So it is easy enough to ask for confirmation in the BEFORE DELETE clause, but what then if the user answers "no"? I tried two things: 1) Copy the current row to a temp record, use a for loop to push all of the higher numbered rows back to their original positions, and copy the temp record back in its original position. This works great, except that arr_count() has been automatically decreased by one and I have no way of permanently setting it back to what it was before the delete. As the manual says, "if you change the value of arr_count() in a BEFORE clause, 4GL will restore the original value at the end of the clause." Calling set_count(arr_count() + 1) is not viable. 2) Enclose the INPUT ARRAY in a WHILE loop and if the user answers "no" to the delete, then EXIT INPUT, but continue the loop and re-execute the INPUT ARRAY so that the delete does not take effect. But of course the user is left back at the beginning of the array when the INPUT ARRAY is reentered. If they were previously 10 pages into the array then they will be confused to be all of a sudden back at the beginning. I tried using the SCROLL statement upon reentering INPUT ARRAY to scroll forward to where the user had been previously. This command seems to be worthless, though, because the correct rows are displayed but as soon as the user begins to use the arrow keys to move up or down then the system overwrites the SCROLLed rows with the rows that were present before SCROLLing. Has anyone successfully come up with a way to back out of a delete? Thanks, Carl Mosley AT&T ctm@mvune.att.com