[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference iosg::all-in-1_v30

Title:	OLD ALL-IN-1 (tm) Support Conference
Notice:	Closed - See Note 4331.l to move to IOSG::ALL-IN-1
Moderator:	IOSG::PYE

Created:	Thu Jan 30 1992
Last Modified:	Tue Jan 23 1996
Last Successful Update:	Fri Jun 06 1997
Number of topics:	4343
Total number of notes:	18308

3960.0. "Messy form-set repainting" by BRUMMY::MARTIN::BELL (Martin Bell, NETCC, Birmingham UK) Thu Mar 10 1994 17:45

I am writing an application to allow a user to edit a "block" of
records (using entry forms), but in between the records the screen
is repainted in a very messy fashion.

The record is edited using a 3 page form-set, and on completion the
user is prompted whether they want to edit the next record, something
like this:

.label LOOP
    form THREE_PAGE_FORM_SET/mode=change/once/save_start=#next_key
    prompt "Press RETURN to edit the next record. EXIT-SCREEN to quit "
    .if OA$PROMPT_DISPOSE ne 2 then .goto quit
    compute #next_key = #next_key + 1
.goto LOOP

... now this all works fine if the user presses RETURN on the first
form in the form-set. The prompt appears neatly on line 24, and if
the user presses RETURN, the next record appears just as if there was
only a single form in the set.

If, however, the user presses RETURN from the 2nd form in the form-set,
the prompt appears on line 24 neatly as before (on form 2), but pressing
RETURN to this prompt causes form 1 to be displayed and cleared, followed
by form 2 (displayed and cleared) followed by form 1 being displayed
with the contents of the next record

Similarly, pressing RETURN from form 3 causes form 1, 2 and 3 to be
displayed and cleared after pressing RETURN to the PROMPT, followed
by form 1 of the new record.

If i remove the prompt completely, everything behaves nicely, i.e.
pressing RETURN to form 2 simply displays form 1 with the next record,
and similarly for form 3, but that is no good, as the user needs to
be able to break out of the loop!

Thus the PROMPT seems to confuse ALL-IN-1 as to which form (in the
form-set) is actually current.

I replaced the PROMPT with an overlay form to let the user press
RETURN (or EXIT-SCREEN), but that then causes the underlying (in
this case MENU) form to be displayed, which is still messy.

Can anyone explain why the PROMPT causes such a problem, and whether
there is any solution?

Thanks in advance,

mb

T.R	Title	User	Personal Name	Date	Lines
3960.1	Still not working ...	BRUMMY::MARTIN::BELL	Martin Bell, NETCC, Birmingham UK	`Fri Mar 11 1994 10:35`	17
	Has anyone got any ideas about the problem in .0????? While the PROMPT function is executing, the form THREE_PAGE_FORM_SET is still current, but on completion, why should it get re-displayed before the next FORM function call? At the moment i am going to try a workaround of having the prompt message be part of another form the looks identical to the first one in the form-set, so that although fields are cleared and filled on the first form, at least forms 2 and three aren't displayed. Even so, i would still like to know how ALL-IN-1 is processing things, so that i can hopefully avoid this problem in future. Your hopefully, mb
3960.2	Wild guesses and suggestions	IOSG::MARSHALL	A glitch in reality	`Fri Mar 11 1994 11:37`	18
	Wild guess... The second time round the loop, the FORM function is trying to invoke the entry form which is still current, which is probably what confuses ALL-IN-1. Maybe a CLOSE_PRIOR just above your .GOTO LOOP line might help? The only documentation on form-flow processing is in the back of the AP Guide, there are flowcharts for all the different form types. Also, if you have any /BLANK or /CLEAR qualifiers, they may be causing problems when ALL-IN-1 tries to process the current form as though it were a new form. Instead of invoking the form /ONCE then having a .PROMPT outside the form, it might be better to use the built-in repetition features of ENTRY forms and incorporate your prompt in the form post-processing to force OA$FLD_EXIT (or whatever) if the user doesn't want to continue. Scott
3960.3	If it was _easy_, we wouldn't have a job!!!!	BRUMMY::MARTIN::BELL	Martin Bell, NETCC, Birmingham UK	`Fri Mar 11 1994 14:27`	30
	Scott, thanks for the ideas. I initially tried a CLOSE_PRIOR immediately after the FORM call, but that caused the PROMPT to display over the underlying form. When i put CLOSE_PRIOR immediately after the PROMPT, the original problem occurred, which seems to hint that it was ALL-IN-1 getting confused trying to put the screen back to how it _thought_ it was, eg. "i was on screen three but that form was no longer current but i have not been requested to show a different form just yet so i will try my best to get back to where i was, er" I think that there used to be a problem with form-sets when you copy between fields, but i created a very simple form-set (no /COPY, /BLANK, /CLEAR infact nothing but the required ENTRY details) and the problem still occurred. We have now got around the problem by defining a keystroke (GOLD X) that if typed within the ENTRY form sets a flag and does OA$FLD_EXIT, and the loop script checks this flag instead of asking the user. This is actually a much neater way of doing things, because to quit the "block operation" is a much rarer event than proceeding onto the next record, so we may as well make this an exception. Thanks anyway for your thoughts, cheers, mb