last week I played a bit with some of the new LotusScript methods described in 8.5 designer help. Two of them I probably don’t understand:
NotesDocument.GetRead / NotesViewEntry.GetRead:
according to help they are supposed to return information about the READ status for a given person. So I wrote a view action that performs NotesDocument.GetRead() on a single selected document. But without success:
the database IS set to maintain unread marks, the given doc IS truly marked as being unread by me, but still the action returns TRUE, i.e.: it thinks that the doc has been read by me. In fact, the action returns TRUE for every doc in the view, no matter its state. I set unread marks using the client’s edit menu as well as another LS action, but the method unvariably returns TRUE. Question: when does the method really regard a doc as being unread by me?
NotesView.ResortView
this one really sounded promising, but then…:
obviously we only can resort a view using columns that have been marked as being user resortable by the view’s designer! If I reference a view that is NOT resortable then apparently the method tries to resort the view using the next resortable column available, counting from left to right. On top, the help documentation mentions two optional arguments, “columnName” and “ascendingFlag”. Of course I first assumed that “columnName” must be the column’s programmatical name, like “$2” or whatever. But no: it’s the column’s title value!
So the bottom line is: I only can use the method on a column that is resortable AND that does have a title value, right?
Please correct me if I’m wrong (in this case I’d love to be wrong, really!).
And: please make sure those new methods find their way into Domino designer’s context documentation / standard help file!
The Document/ViewEntry.GetRead do work to our knowledge. XPages uses them as a matter of course internally. I suspect you are running into caching behaviors. The backend is a server package and is obliged to cache unread marks tables in order to reach performance requirements. The cache is not refreshed on every query, but the queries are structured in such a way that it works out. The backend Database must be killed in order to rebuild the cache. To test the method itself, bounce the Database, or the Client and reget see if they read out correctly, or you can test it against a database other than the CurrentDatabase, which does not persist.
As for ResortView, the design requirement was Client-facing so accepts the ViewColumn.Title, as one would see it on the Client. This was done for ease of use so you would not have to do the sometimes intricate column index mapping necessary on very complex views. We do that internally. The feature has not been available previously, as you seem to suggest. It is new. Necessarily, it operates on columns defined to be sortable, since the heavy lifting must be done at View indexing time. You do have the ability to redefine sortability of the column design. The ability to sort an unsorted column at runtime is not planned.
#1 - Could be that by simply “opening” the doc it’s being marked as read by you? Then on the next line where your code is checked it’s no longer “unread” to you? Just a stab.
#2 - Not sure, didn’t actually know about this method but I’ll check it out.
Good idea, but I don’t think so: as I wrote before, after having marked a document as being “UNREAD” the method still returns that the doc has been READ by me. If however I restart my Notes client (need to make sure that I also shut down an open designer client instance!) the next time I call that method it recognizes the doc as being UNREAD.
BTW: same is valid the other way around…
Doesn’t really make sense to me, but maybe I’m just to dumb to see how it’s supposed work