Notes Crashes on UiDoc.save from Embedded View

HCL Domino Domino Forum
1

We have an embdded view on the main document. What we are doing is if the user opens up a document on the embedded view we are going to look to see if the main document was in editmode, and if so save the document, and then open up the document from the embedded view. (Note: when the user closes the child document, we will re-open the main document).

The code in the Initialize section is…

Set sessionNavigate = New NotesSession

Set dbNavigate = sessionNavigate.CurrentDatabase

Set wsNavigate = New NotesUIWorkspace



Set uidoc = wsNavigate.CurrentDocument

Set docNavigate = wsNavigate.CurrentDocument.Document

the code in the Queryopendocument of the embedded view is

If uidoc.editmode = True Then

Msgbox "try save first"

Call uidoc.save

Msgbox "Back from the save"

End If

End Sub

I get the msgbox for the try save first, and I put msgbox in the form in querySave and postsave events of the main form, and these fire off as well.

I Never get the ‘Back From Save’, that is when notes abends.

You’ll note that i use navigate, since i read in the notes 6 forum that using the same global variables in the main form and the embedded view may cause problems.

Wondering if this is something with version 8 bug or I missed something else completely.

Thanks

John

2

Subject: Interesting dilemma!

Not sure if you can do what you want. I had this issue before. Perhaps someone out there knows the answer. My work around was to create 2 embedded views. One that shows when the main doc is in Edit mode (i.e. vwResponses-Edit) and another when the doc is Read mode (i.e. vwResponses-Read). So, the script in the view would read the view name and decide what to do.

Ah! I also use Environment variables to pass the UNID of the main document so I can grab the handle to it via the backend.

I will watch for others to see if there is a better way.

3

Subject: We do have a work around

Jose,

We do have a work around, it took hours to figure it out, and will cost us a lot of time. It seems the best trick is to have the view open event validate the form,in case the user changed something. We then save th4e document by a doc.save rather than as uidoc.save. We then set the saveOptions to “0” and continue on.

Our other issue is that we are saving changes on certain fields, and that was going to a rich text field, but we are hoping that Trigger Happy will solve that problem, and we cna remove a lot of code.

Cheers,

John