I have an application where the user can create documents with a button click. Often the default values (that are calculated in the form), will do and the user wants to save the document without changing any field.
Problem is:
When the user presses escape, the document disapears without being saved, while the user should have the choice to save or disregard the document.
I know I can add a button to save the document, but most users (including myself) are used to the ‘escape → save? yes/no’ sequance.
Is there an easy clean way to make a newly composed document ‘dirty’ so that the save dialog box will appear?
Subject: How to force the save dialogbox to appear when accepting default field values?
What if you add and then remove a field in postopen?
Subject: RE: How to force the save dialogbox to appear when accepting default field values?
Hi,
I tried to set fields in the postopen-event : it doesn’t help.
Even when I change field contence in the UI in the PostOpen event (EditGotoField, FieldSetText) : Notes won’t ask to save.
I made a workaround now, by setting SaveOptions=“0” and writing my own ‘Save dialogbox’ in the QueryClose-event.
Still, I would like to know if one can set the UIDocument to ‘unsaved’.
Subject: RE: How to force the save dialogbox to appear when accepting default field values?
Just make a field change in the Queryclose event. You could probably just create and then delete a field, to have no net difference. But first, check whether the document is in edit mode. Also check whether the save has already occurred.
Subject: simpler solution
adding a refresh in the button that creates the document seems to do the trick, thus:
@Command([Compose];“MyForm”) ;
@Command([ViewRefreshFields])
I suppose that will be the simplest (and best) solution.
Subject: Alas … that doesn’t work either!
It looks that any field changes made in the form’s events doesn’t set the ‘dirty’ flag.
As I have computed fields, a F9-press + Escape does make the save dialog box appear, so I have tested with refreshing fields in PostOpen, and QueryClose event, but that doesn’t help either.
This works though:
Creating a NotesTimer in the PostOpen event that does a NotesUIDocument.Refresh after 1 second : this makes the save dialogbox appear after an Escape-press!
Subject: RE: Alas … that doesn’t work either!
I believe you’re overgeneralizing. I think what’s actually happening is that the Postopen and the first field’s Entering event occur before the point in time where the Notes client decides to start “counting” changes. The Queryclose event must happen after the decision has already been made whether to prompt the user to save.
I expect that changes made in other form events – postrecalc for instance – or in the queryclose if it also sets Continue = False the first time it’s called – will flag the document as “dirty.” I’m not saying this is a solution to your original problem – just that you shouldn’t assume that all form events are not counted when prompting for save.
This NotesTimer thing seems like a kludge to me. There will be trouble if there’s a dialog open (e.g. appointment reminder) when it triggers.
The way I’ve done this in the past is in the code that opens the window – have it compose the new form, then change a field.
Subject: Thanks for your answers …
Yep, as I mentioned in my other post, the best solution is to set/change a field in the formula/script that composes the new document. That seems to work reliable.
The NotesTimer has never been an option to use in production, but it showed that the change could be enforced if it was done outside the form PostOpen event.
I could make use of the undocumented uidoc.ModifiedSinceSaved property too, but I supposed it’s undocumented for some reason, isn’t it?
Whatever, I have a reliable solution now, thanks again for taking intrest!
Joris
Subject: RE: Thanks for your answers …
I believe that the most common reason for undocumented features is that Iris hasn’t decided to commit future client code streams to include the feature.