Prevent user from cancelling or leaving a form

[broche]

NT 8.21
CL 9.0

Best way to prevent user from exiting a form by either cancelling or clicking on the 'x'
I need the user to complete the form once started.

Thanks.

[kevin plummer]

There isn't - you will need to think of a different strategy.

[Bruce]

>> I need the user to complete the form once started.

there is simply no way to force them to complete the form. At the very least closing the browser, or turning off the machine will leave the form in an "incomplete" state.

What you really want is a way to tell the difference between complete, and incomplete records. This is, of course, a side effect of using auto-numbering, and that's been discussed before. (ie Autonumbering is bad).

Personally I use a "date/time started" field, and a "complete" field to identify errant records. The former are primed when the form opens, the latter when it is saved. A background process can then clean out old, incomplete, records.

cheers
Bruce

[broche]

Thanks to you both
I changed 'Strategy' over the weekend and turned off autonumbering.  Made it so the user had to go back into the record so that they could upload files.
I had a rebellion on my hands this morning and had to change it back - oh well, I won't do that again.

Brian.

[kevin plummer]

You could try auto saving the form on an insert - so when they insert a record, you save it straight away and change status to a change record for NT. That way if they don't complete the form it is already saved and they would have to delete it. There are also strategies on how to deal with orphaned child records if that is the real problem.

[Bruce]

Hi Brian,

>> I changed 'Strategy' over the weekend and turned off autonumbering. 

good idea.

>> Made it so the user had to go back into the record so that they could upload files.

bad idea. It's not necessary to do this to the user. I'm not surprised they're unhappy.

if you are using a string GUID identifier, then prime the guild in the Priming tab,
for example in my apps I make a global, unthreaded StringTheory instance, called glo:st
then I prime the GUID to
glo:st.Random(16,st:Upper + st:Number).

Actually I do all this in the dictionary itself so it "just works" in the code. I'll show it at the thursday webinar if you like.

Cheers
Bruce

[broche]

Yes please Bruce, would love to see it.
App is released and going well with one customer, although I am finding that I have to streamline a lot - my initial design is a little clunky and they are used to a full 32 bit app.

Brian.

[CaseyR]

Hi, Brian

I am assuming you need them to complete the form once they start because they may add child records that would be orphaned if they moved on without saving.   My solution to that problem is to load and display the child records in a In Memory table and only transfer them to physical tables after the parent table has been updated.  For even greater certainty of data integrity,  us an In Memory table or memory variables to display/capture the user field inputs, then wrap all the physical table processing in logout/commit with rollback on failure,.

[broche]

Thanks Casey,
The memory table you use is on the server so I presume you differentiate between who is doing the uploads by a usercode in the memory table record?  This would also be a nice one for the Thursday Webinar

Brian.

[CaseyR]

Yes, you need to include the SessionID in the memory table.   You also need to clear the memory table of records with the SessionID in Pre-Insert, Pre-Update for the form.