I have the need to do something each time the file selection is changed. Thus I miss an OnSelectionChange event type in the scripting API. Is there any other way to be notified about each selection change?
What do you need to do? There may be a other way.
We scan a lot of our correspondence (letters, contracts, offers, invoices, etc.) as PDF documents. These PDF documents (we have thousands of them) are maintained on a file server within a complex directory structure.
I installed the new DOpus version to find out how DOpus can help us by organizing and browsing through all these files. To get a quick preview during navigation I always have the PDF viewer plugin enabled (vertically maximized but horizontally splitted).
Unfortunately in some cases the PDF viewer runs out of sync with the selected file. You can imagine that it is pretty bad to have a file "Offer for Mr X.pdf" selected (marked on the screen) but the PDF viewer shows "Offer for Mr Y.pdf" because this file was previously selected and DOpus didn't update the viewer ("Offer for Mr Y.pdf" may be still on the screen even if the file is placed in a folder tab that was previously closed). Obviously it doesn't help that the viewer can be manually refreshed (e.g. by pressing space) because occassionally your are simply not aware that viewer and selection are out of sync.
There are four major cases the viewer runs out of sync (viewer isn't updated to the new selection):
- If you close the current tab.
- If you change the tab to the left or right.
- If you switch the focus to the other file display (in dual-view mode by pressing tab).
- If you perform a quicksearch by using the FAYT field.
Until you fix this (confusing) behaviour I had the idea to write an event script that updates the viewer by passing the current selection to the Show command. There seems to be appropriate event types for tab changes but not for selection changes.
That's the reason why I ask for the selection events. It can be instantly used to keep the viewer more in sync than DOpus currently does by itself.
I can express my expectation more formally:
The viewer plugin should be kept in sync with the currently selected file in the same way as the other panels already do. It looks really strange having the metadata panel docked to the bottom and the viewer panel docked to the right and seeing the metadata panel always following the selection (as expected) and the viewer plugin sometimes does not.
The first three cases can be handled by existing events, since there are script events for tabs being activated etc. Tab-Labelizer is probably a good example script that handles the relevant events.
I don't think there's a (sensible) way to handle the 4th case at the moment. Not sure if it would make sense to run scripts whenever the selection changes, as that could slow things down, but changing the way the viewer responds to selections may happen.
Thanks for the quick reply! 
This issue will immediately become a non-issue when you change the viewer behaviour to responds to selections identical as the metadata pane. 
If you have concerns regarding the viewer performance maybe it would help to allow the viewer to be pinned by a checkbox (only refreshed when triggered manually). Or the viewer can have a delay time that is automatically adjusted regarding to the current load (e.g. the delay for the next file will be the time the last file took to load)...
That may perform not well for different files. Think about a PDF file that may take 4 seconds to open. At least I don't want to wait 4 seconds for the next textfile to be opened.
I think the current implementation (skipping intermediately selected files if the viewer plugin can not follow) is perfectly applicable for high frequent file selections. On my machine I can hold CURSOR_DOWN and iterate over hundreds of PDF files in a sequence without any noticable lag (certainly the CPU is eating all those PDFs but the DOpus UI always reacts smoothly).