Monday, June 29, 2009

New NotesUI-bug found in Notes 8.5 (includes workaround)

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 'True then False when settings doc exists

'// If new doc, check for existing settings doc
If Source.IsNewDoc Then
Dim settingsDoc As NotesDocument
Set settingsDoc = s.currentDatabase.GetDocumentByUNID( UNID_SETTINGS )

'// Set static unid on new settings doc
If settingsDoc Is Nothing Then
Source.Document.UniversalID = UNID_SETTINGS
'// Open existing settings doc
Dim ws As New NotesUIWorkspace()
Call ws.URLOpen( settingsdoc.NotesURL ) 'Works
'Call ws.EditDocument( False, settingsDoc ) 'Does not work
Source.Close True
End If
End If

Exit Sub
If Err = 4091 Then Resume Next 'Invalid UNID
End Sub

>> Bugreport


Jan Schulz said...

Unfortunately, URLOpen does not allow to open a document in edit mode ( Ideajam: Make all notes URLs actions useable in the client)

On the other hand, I don't understand why you can't check if the doc exists before opening the preferences?

Tommy Valand said...

You're correct. I've set "Automatically enable edit mode" on the form.

I'm not exactly sure about what you mean with your question..?

The reason I have the code on PostOpen is to ensure that only one settings doc can be created. Also it was a little experiment on my part, to see where it would be optimal to set the static UNID.

The QueryOpen event on NotesUIDocument doesn't allow NotesUIWorkspace.EditDocument/NotesUIWorkspace.URLOpen.

Unknown said...

The forum is really not the way to report something like this. I think you should open a PMR which is the only way to have this addressed.

Tommy Valand said...

The reason I started posting the bugs I found on the forums/in my blog was partly due to how easy it is (Opening a PMR may be just as easy, I've never done it), and also to make the public aware of potential bugs/workarounds.

I'll try to make a demoapp/attach it to a PMR tomorrow.

Jan Schulz said...

Currently you are creating a doc and then check in the postopen of the form if there is a better doc. How about first checking if there is a doc with that UNID and only if there is none, create one, assign the UNID and then open it?

Tommy Valand said...

I think I see where you're getting. This code wasn't meant as a way to open/create the settings document. It's partly an experiment on my part, seing how difficult it would be to prevent people from creating multiple settings documents, if they went the Create way.

Of course, it's better to set that the form shouldn't be shown in the create menu.

The reason I posted the code was that it seemed to trigger a NotesUI-bug.

What I tend to do in an outline to create or open a settings doc.