Category Show-n-Tell Thursday
Bookmark :              


During my time in the code-monkey-cave, I discovered a couple of very painful things when working with framesets in Notes (I emphasize Notes because when I mention framesets people inevitably miss the fact that I mean framesets in Notes, and assume I mean frames on the web. Silly readers - but not you, of course - it is those other silly readers. But I digress...)

Problem 1: Single clicks when I don't want single clicks!
I have a form that displays in the right frame of a frameset - call this frame "MainFrame". In that form is a tabbed table with 4 tabs. On the third and fourth tab there is an embedded view. I use a bit of trickery to cause those documents in the embedded views to be open in small dialog boxes, not in the main frameset. So the main doc stays open in the frameset, and the embedded view docs open in dialog boxes. As a side note, this doc is never viewed in a view - there is an outline entry that launches this doc into the frame, and that is the only way through the UI to get to this doc (hence there is only one of this doc in the db). Got the picture?

The problem is that when you navigate to one of the embedded view tabs, the first document in the view opens automatically!! No clicking at all! If you switch tabs a few times it quits doing that, but then whenever you single-click on a document in an embedded view it launches it. This is NOT intended behavior.

Cause and Solution
Well, I talked it over with John Head, and we found the problem - I had set the "Default target for links in frame" property to itself ("MainFrame") for this frame. This seems to cause the problem I was experiencing. Changing this property to nothing fixed the problem. John said that in general you should never set a default target frame to itself, and based on this evidence I think that is good advice.

Time to move on to problem #2...

Problem 2: Prompting to save when I open an embedded view doc?
OK, picture the same form/frame/embedded view/dialog scenario as above. Now we're placing the doc into edit mode, and it is still in the frame ("MainFrame"). All is well so far. We click to one of the embedded view tabs - since we fixed the problem in #1, it works fine. Now we double-click an embedded view doc to open it (remember it opens as a dialog box) - and we're prompted to save the current document. Huh?

Cause
This one actually makes sense, once you think about it carefully. You have a document being displayed in a frame, in a frameset. That frameset is in a Notes window tab (those things across the top of the notes client showing all the crap you have open). When you change the state of the document to edit mode, it is still in a frame. The frame can only have one document open at a time - it doesn't open new Notes window tabs like non-framed dbs. When you double-click a document, the Notes client assumes that it is going to open the document into the same frame; but you've got that doc in edit mode, and you have "clicked" something to "dirty" the document, so it must close the current document to show the new doc. Therefore it needs ask us to save the document before it can continue and open the new doc. And even though we're opening the new doc into a dialog box, it doesn't know that at the time - it (the client) thinks it has to replace the current doc with the new doc, so it needs to get you to save or dismiss it to open the new doc. Make sense?

And before you ask - that prompt to save occurs before the Initialize event of the embedded doc form fires, so there really is no clean way to do something like set SaveOptions = "0" temporarily.

Solution
My solution was the cleanest way I could find to get around the situation. When the user places the document into edit mode I force the edited version of the document to be open outside of the frameset, in its own Notes window tab. To accomplish this I did the following:

I placed the following code in the QueryModeChange events of the form:

	If Source.EditMode = False Then
		Continue = False
		Call ws.SetTargetFrame("")
		Call ws.EditDocument(True, thisdoc,,,False, False)
	End If

This intercepts the editing of the document and forces it into a new Notes window tab by setting the TargetFrame = "". Also notice that the newInstance parameter (the last parameter) of the Call thisuidoc.EditDocument method is set to False. By setting this to false, the user cannot create multiple edit-mode instances of the document; if he tries, it will simply switch focuse to the current edit-mode version.

Now, as I mentioned earlier this doc is never viewed in a view - so I know that when the user sees this doc, it is always in read mode at first. The doc is created by an automated process (not composed by the user), and is access through an outline entry item that sets the doc into the frame. If, however, you wanted to use this technique in your app you can also place that code snippet into the QueryOpen event of your form as well, and it should work fine.

Conclusion
Hope this helps someone later on who struggles with the same issues with framesets in Notes that I had. These were a PITA to chase down, and by putting this out into the geek community hopefully I can save others the same pain.

Rock
**All good things arrive to them that wait -- and don't die in the meantime. -- Mark Twain