But I'm pretty sure there are neater way which may involve repeat control and pager. But that might require a quite some big changes to your "docPage" xpage and maybe some changes to the click event in your dataview which directs you to the "docPage".

So since I don't know if the click event in your dataview is programmable or not and to avoid the big change in your "docPage", you can try the following solution:

1. Put the following parameter in the "Next" button in your "docPage":

2. In the "docPage afterPageLoadEvent, put the following code:-

I've tested the above with view that has 70k documents in a local database. It might be slower if it's a remote database.

Thanks for this! Really appreciating this great help!  I am still struggling a bit however; as my view data sources are dynamic I cannot hard code a view name.

Basically my application consists of a number of "viewPage" Xpages displaying views from various .nsf's. The view data sources are set as custom properties on the "viewPage" Xpages.

All "viewPage" Xpages share the same dataView custom control called cc_dataViewControl. This dataView custom control points to the docPage Xpage as pageName to open with the doc data. Thus there is only one DocPage. 

This is my code:

On every "viewPage" Xpage the view data source is defined by custom properties like this:

<xc:cc_dataViewControl
    sourceDb="KS/ksfelles2.nsf"
    viewName="xInnhold">
   </xc:cc_dataViewControl>

The shared cc_dataViewControl appearing on every "viewPage" is defined like this:

<xe:dataView id="dataView1"   collapsibleDetail="true" pageName="/docPage.xsp" var="rowHandle">

and of course this custom control has the custom properties referenced as well.

Database is sourceDb and view is viewName, as far as custom controls are concerned, then the actual db and data source is defined on the viewPage Xpages

---

Then on the "docPage" Xpage the only data source at present is this, from the parent dataView Xpage:

<xp:dominoDocument var="document1"
       action="openDocument"
       documentId="#{javascript:rowHandle.getNoteID()}"
       databaseName="#{javascript:compositeData.sourceDb}"
       formName="#{javascript:compositeData.formName">
 </xp:dominoDocument>

pointing to the rowHandle var of the dataView custom control on the parent Xpage. 

These custom properties are not defined on the docPage, only on the preceeding view page.

So what I'm too blind to see after looking quite a bit is How to get a handle back to the viewPage and select the next doc in that dataView?

Can I have a view data source on the docPage also pointing to the parent viewPage, and utilize the rowHandle?

Yes, if I was only more fluent in scripting...

Thanks in advance...

Vidar

I haven't had the time to recreate your application but maybe you could try the following:-

In each of your "viewPage" Xpages, in the afterPageLoad event, put the following code:-

Make sure the above code is only used in "viewPage" Xpages. Else there might be error in your "docPage" later on.

Then change the 1st line of the code that I suggested previously to the following:-

I think that I would back up and re-think what I was doing. 

When beating your head against the wall the first step is to stop beating your head against the wall and rethink the problem.

XPages give so many ways to accomplish a task that sometimes we can get locked into a method that is possibly not the best method to accomplish the task.

I would start by getting a list of UNIDs for all of the documents in the set and probably place them in a sessionScope variable, say ssUNIDs, do all of this in the Before Page Load event on your docPage. I would set a sessionScope variable call it ssPos =0. In the Document ID of the dataSource of your docPage write some JS or Expression Language to get the ssPos value from the ssUNIDs scoped variable and I'm not sure but I think you would do a     context.reloadPage() as I'm not sure that you could just do a refresh. Now you could create a Next as well as a Previous button and all they would need to do is increment/decrement ssPos and away you go.

The Before Page Load event would contain all of the logic to build the list of UNIDs and would determine the sequence etc. and because you are using UNIDs the docPage does not care what view they are in.

Just as an aside using the UNID as the key to the documents in this case makes sense, however, I never use the UNID to relate common documents because the UNID can change when a save/Rep conflict occurs so is not a reliable key. I use @Unique to generate a unique key for a 'parent' and then set that value in each 'child' that I create but I never use the response document structure way to many landmines in that.

Here is a link that gives more detail on using @Unique, also David Leedy has posted on the same issue

http://www-10.lotus.com/ldd/xpagesforum.nsf/xpTopicThread.xsp?documentId=04BE41D3A2AD108C85257D480010D628#1721EDABA2B38E1D85257D48005C9385