I know recently 852 and 853 they have made significant improvements to view navigator.

Or to do it in bulk instead of one document at a time, first define two NoteCollection objects nc1 and nc2, with both containing all documents using the setSelectDocuments(true) and buildCollection() methods. Next call nc2.intersect(view) which gives you only the documents in the view. Finally, call nc1.remove(nc2), which gives you all the documents that were not in the view.

If you have multiple views and/or folders to work with, you can do it in a loop. I.e., after each remove(), call nc2.clearCollection, then call nc2.add(nc1) so once again you have two identical collections (all docs minus the ones that were removed in previous iterations), and repeat the process of intersecting and removing.

Note that I haven't tried the bulk approach, but I have a feeling it should be significantly faster because it's never actually opening documents.

Have done it in LS with NotesViewNavigator. It's time to compare both methods regarding performance

You've convinced me to change my approach.

Like everything it's "horses for courses" and "more than one way to swing a cat".

1. The method you have above

2. The method you have above changed to only fetch the selection formula once and then pass that in instead of the view

3. A method that creates a view navigator from the view and uses .gotoEntry(doc) on that

4. A method that takes an already-created navigator instead of the view

Somewhat freakishly, the average run times of three attempts at each were about halved, each in order:

1. 55-59s

2. 30-31s

3. 14-15s

5. 6s

So, at least if you're going to be running the method quite a few times, using the view navigator is much faster.

To take your example above - SELECT !Form="Foo"

Phil.

I'll leave it with you if you want to look in to it any further ;)

Based on the principle that the selection formula for some views is representative of the business logic for a database, it shouldn't be too hard to think of a case where you need to check whether a document is in a view or not.

I also kind of wonder how it would work in oddball scenarios like a document qualifying for the selection formula but not visually showing up in the view because its parent isn't there.

I bow down to your superior wisdom! Now you've explained it it makes sense. Without the explanation I'd expected the more obvious result of it returning either a 1 or 0 | "1" or "0" | "True" or "False" .

Thanks for the explanation. I continue to learn.

in formula language there is no "boolean" data type (nor "integer" or "real" etc.). There just is "number" and "string".

And @True is a number (1), @False is 0.

As you are evaluating in java, which has strong typing, you will get the number data type which should be able to hold the returned value - which is the double data type.

To avoid this kind of trouble I tend to use formulas which return strings, e. g. by wrapping the formula into an

@if (....; "1"; "0");

Not pretty, but more reliable. I also like to wrap the formula with an @If (@IsError(...); ...), so that I can check the results - instead of the exception handling.

@Formulas throwing errors are bad, not only in forms - you never know what is going on without catching the errors in every single formula...

By the way:

Your formula probably might not work for views with response hierarchies, e. g. selection formulas containing @Responses or @Descendants. But I haven't tested this.

Hans-Peter