Update: The bug(?) isn't as serious as I first thought. The settings document wasn't closed, but it was sent to a frameset of another application. In the other application, an action calls NotesUIWorkspace.SetTargetFrame. I'm not sure if it is a bug, that a document from another application ends up in this frameset. For all I know this is just Notes' quirky way of doing things. If I call
setTargetFrame("someRandomValue") before NotesUIWorkspace.EditDocument, the code works as designed.
--
I'm back working in the client again. It seems every time I'm working on client code, I discover a new NotesUI-bug. :-\
Purpose: When user tries to create a settings doc, check to see if one already exists. If yes, open the existing doc (by static unid), else set static unid, continue.
I'd have thought it would be as easy as (in PostOpen) Source.Close, NotesUIWorkspace.EditDocument. And it would, if the user was running Notes 8.0.X. In Notes 8.5, the client closes both the "Create Settings" instance, and the LS instance if the user opens the Settings-form when a settings doc already exists (see code below).
The workaround is easy: Source.Close, NotesUIWorkspace.URLOpen
Even though it's easy to make the code work in 8.5, I shudder to think about how many existing applications that's going to misbehave if the user upgrades to Notes 8.5.
Sub Postopen(Source As Notesuidocument)
On Error Goto handleError
Print Source.IsNewDoc
If Source.IsNewDoc Then
Dim settingsDoc As NotesDocument
Set settingsDoc = s.currentDatabase.GetDocumentByUNID( UNID_SETTINGS )
If settingsDoc Is Nothing Then
Source.Document.UniversalID = UNID_SETTINGS
Else
Dim ws As New NotesUIWorkspace()
Call ws.URLOpen( settingsdoc.NotesURL )
Source.Close True
End If
End If
Exit Sub
handleError:
If Err = 4091 Then Resume Next
End Sub
>> Bugreport