This is perhaps only for documentation purposes - but I had some doubts about my solution. In a script that I use to react on changing folders, I found that Opus did not detect, in Dual lister mode, that I switched from source to destination or vice versa when this change did not involve also clicking on another (non-active) tab. So in addition to OnAfterFolderchange() and OnActivateTab() I added the event handler OnSourceDestChange() to handle this situation ) but then I found out that this event handler gave me the wrong tab - that is: the tab that is “left behind” when you change from source to destination:
function OnAfterFolderChange(AfterFolderChangeData) {
// Called after a new folder is read in a tab
if (AfterFolderChangeData.result != true) {
DOpus.Output("Folder was not read properly!");
return;
}
RunNewFolderFunction(AfterFolderChangeData.tab);
}
function OnActivateTab(ActivateTabData) { // Called after another tab was clicked
RunNewFolderFunction(ActivateTabData.newtab);
return false;
}
function OnSourceDestChange(SourceDestData) {
// We can't do anything with the received object because OnSourceDestChange()
// gives the OLD tab. So we fetch tne new one from DOpus, then run our core function:
var newtab = DOpus.Listers.LastActive().activetab;
RunNewFolderFunction(newtab);
}
function RunNewFolderFunction(tab) {
//... Whatever it is we want to happen after the folder change
}
I suppose this is on purpose: SourceDestData gives the old tab as an object, not the new one. Now this was easy to solve, by invoking DOpus.Listers.LastActive().activetab.
In fact I first tried other things - the event handler OnTabClick() was the closest thing I could find, unfortunately this event handler does not react on a standard mouse-click, it has to be a combination with a key (like CTRL or ALT, etc) - but of course that’s not what one wants to do at every folder change (not to speak of its side-effects - in this case: locking the tab, or whatever). I suppose this is also by design - although I do not understan why OnTabClick() seems designed not to react on a standard mouse click. Would it hurt anyone if it did? My feeling is that this event handler would have been the more straightforward way to manage tab clicks.
But, as I said: the solution via the OnSourceDestChange() handler works, and this post can be considered “for documentation”.