@DialogBox saving when it shouldn't

HCL Domino Domino Forum
1

I am using

@DialogBox(“Audit”; [NoOkCancel] : [NoCancel] : [NoNewFields] : [NoFieldUpdate] : [AutoVertFit] : [AutoHorzFit] : [SizeToTable]; “Turnover Dashboard”)

On the Audit form I have 3 buttons that do various actions. None of the fields in the DialogBox form should be saved back down to the main document which is why I use [NoNewFields] and [NoFieldUpdate]. Everything worked fine until I added some code to each button to record that the action buttons were used. In order to get a handle to the main document [from which the DialogBox was called] I have a field on the Audit form that has the UNID of the main document. I simply grab that value to get the document so I can write a date value to a field to capture that the button was pushed. Since adding the code all changes to any fields on the DialogBox get written down to the main document. New fields on the DialogBox also get written down to the main document but I don’t want either of these to occur. The DialogBox is still open when I call the save from the buttons. Not sure why this is happening and logically thinking I don’t feel that it should. Here is the code I added to the buttons that has affected the unexpected saving of field values fro mthe DialogBox to the main document:

Dim thisdb As NotesDatabase

Dim dt As New NotesDateTime( "" )

Dim pdoc As NotesDocument

Dim hist As NotesItem

Set thisdb = ns.CurrentDatabase

tmpID$ = uidoc.Document.docUNID(0)

Set pdoc = thisdb.GetDocumentByUNID(tmpID$)

Set hist = pdoc.GetFirstItem("History_b1")

Call dt.SetNow

txt$ = Cstr(dt.DateOnly) & " " & Cstr(dt.TimeOnly) & " - " & "executed."

If pdoc.History_b1(0) = "" Then

	pdoc.History_b1 = txt$

Else

	Call hist.AppendToTextList( txt$ )

End If



Call pdoc.Save(True, False)
2

Subject: It sounds like you are the one doing the saving…

The Notes client caches NotesDocument objects, and when you’re in a dialog the situation is a little ambiguous because you’ve got a document in the dialog that might be different from the one in the document window, but they have the same UNID. So I think when you get the document by UNID, you might actually be picking up the cached document from the dialogbox, that has the dialog fields.

Maybe you could send your signals back via environment variables that the code that called @Dialogbox would read, instead of writing them directly to the document?

Or you could dump the cache by using the Delete statement on the document object, then get it again using the UNID.

3

Subject: I like your thinking but …

logically, even if I was saving the document in the dialog box, given the [NoNewFields] and [NoUpdates] params of the DialogBox they should not be writing back down to the underlying document. Also, how could GetDocumentByUNID retrieve a document that has not yet been saved to disk (the document in the dialog box)?