Troubles with views

Search DominoPower's 11,323 Lotus-related article archive

Home
EasyPrint
News details

Articles-only

Twitter Feed

PROGRAMMING POWER
Troubles with views
By Mick Moignard

Here's a short piece with some tips on using Notes views programmatically from LotusScript. And it may be a first for DominoPower: it was written entirely with the Notes 8 document editor.

We had an interesting error come up in one of our project's agents last week, one that took us a little while to work out what the cause was. The agent is one that's run by hand from the Actions menu, and is intended to operate on the document under the highlight bar in the view that's open. That's usually one of a number of views that shows main documents and some of the responses to them. Sadly, this isn't the only problem report against this agent, but it was one that vexed us for a couple of hours while we tried to work it out.

The problem was this: when it was run against the default view, it worked just fine. Being the default view, that's how it was usually run. But if it was run against one of the other views, it failed with a 4151 error -- NOTES_DOC_NOTINVIEW, when to all appearances, the document in question was in the view -- because, of course, it was the one highlighted.

You can imagine that we puzzled on this for a while. Here's a simplified version of the code that shows the gist of it:


dim sess as new NotesSession

dim db as NotesDatabase

dim unProcesseddocs as NotesDocumentCollection

dim view as Notesview

dim maindoc as NotesDocument

dim child as NotesDocument



set db = sess.CurrentDatabase

set view = db.GetView("defaultView")

set unProcesseddocs = db.GetUnprocessedDocuments

set maindoc = docs.GetFirstDocument



set child = view.GetChild(maindoc)

It was on that last getChild statement that the failure occurred, when we started from a view that was not the default view. We read the help documentation about getChild. We ran the code in the debugger. We could see that maindoc has been instantiated. We could see maindoc in the view we started from -- obviously, because we started from it. We could also see it in the default view. And we checked that by UNID to be absolutely sure.

It became clear that the problem had to be how "maindoc" was identified when passed to view.GetChild, and as we explored with the debugger, we started to understand the problem.

When you get a document from the db.UnprocessedDocuments collection, it comes with the ParentView property set to the view that was displayed when the agent was started -- which, by the way, is contrary to what the help says. It says "If the document was retrieved directly from a database or a document collection, the ParentView property returns Nothing."