I don't know when it began, but suddenly DO is slow showing files in lister on first run. After a reboot (and DO autorun) it took up to 5 seconds until dirs/files in lister are shown (the active tabs are local SSD devices). When closing and reopen DO is fast as usual.
Occurs on my PC and Surface.
Are you using PF-XChange Editor? If so, I'll try to find a possibly relevant post. If not, I won't bother.
Lol, yes, bought it yesterday (PDF-XChange Pro).
Okay, after uninstalling PDF XChange DO is quick again. Any solution to make them work together without slowing down DO?
Edit: When uninstalling the shell-extensions, DO works fine again. So is it a DO or PDF bug?
It's most likely a PDF-XChange issue, since no query Opus makes into a shell extension should cause that kind of delay unless there's something wrong with the shell extension or the query is asking it to look at a slow resource (which would probably affect other shell extensions, and can probably be ruled out).
As shell extension only includes "open with" and "merge", I leave it uninstalled. Thanks.
If no one reports the problem to them (and provides whatever info they need) then it'll never get fixed.
I will do, but currently collecting to put all in one mail! Most support doesn't work like this one, I'm still wating months for Synology, Vivaldi, ...
For what it's worth I've been using the PDF Exchange Editor Pro since last September and have never had a problem with it and Opus.
Maybe you didn't notice, because if you don't open DO for a while on first login (after reboot) you won't see any difference. I tested it on 4 devices, behaviour on all is the same and after uninstalling shell-extension, everything is ok again.
I'm new to XChange Pro, but it seems to be best alternative to Acrobat DC (don't want abo) or Pro 2020 (no abo, but less features than DC).
See Apparently misbehaving PDF-Xchange Columns Extension
I did report the issue to Tracker Software and got the following reply which I can't say I really understand:
The Column and Properties sheet handlers both accomplish the same thing, but one is the "legacy" version of the handler. With regards to Windows explorer, the "Column handler" is for windows Vista and Up, while the "Properties sheet handler" is for everything prior. We still offer both however as some 3rd party applications make use of one or the other, and we cannot discern which they will need. All that this accomplishes is offering some additional information in the columns of these applications, such as the PDF specification of the file.
I will forward this report to the relevant Development team members so that they can look into it.
There were no further replies in the thread so I don't know if anyone actually looked into the matter.
I've been perfectly happy with the shell extension indicated in my referenced post disabled,
I'll report tomorrow, but as said, I can live w/o their extension.
I had a quick look and was able to reproduce the problem and make a process dump during the delay, which happens when their XCShMain.x64.dll is loaded in response to us calling their IColumnProvider::Initialize.
It looks like XCShMain.x64.dll may be doing more in its DllMain than it should, which can cause delays or even deadlocks at times.
(Although the exact rules about DllMain from Microsoft are frustratingly vague and boil down to "do as little as possible", a deep stack trace ending in a CreateFile call seems potentially wrong. I obviously can't see their code to know exactly what it is doing, though, so this is just a guess and it may in fact be fine.)
Thanks Leo, sent report incl. link to this thread.
BTW today I've noticed, that shell-extensions include preview-handler, so they hopefully fix it.
I think the only one you need to disable is the Column Handler, which won't affect the Preview Handler. It's this one if you're using ShellExView:
Alternatively, in Opus, adding {D8716A0E-4E9F-4D3F-BF1B-3460D86BB310} to Preferences / Miscellaneous / Advanced [Troubleshooting]: ignore_context_menus seems to be enough to fix things, at least from my quick testing.
(ignore_context_menus also blocks some non-context menu things these days.)
Leo, first, ignoring context works. Amazing. Second, big thank for your continuous support and unbelievable know-how.
Edit: The devs of XChange now noticed this issue, I'll report any news from their side.
Small question: The entry in "ignore_context_menus" won't be saved with prefs. On restore the entry is empty. Is this wanted?
It is saved. Check that your account has permission to write to this file/folder:
C:\ProgramData\GPSoftware\Directory Opus\Global Data\globalprefs.oxc
Yes, its stored in globalprefs.oxc, but the globalprefs.oxc not within DO-prefs-backup-file. After restoring Windows the old globalprefs.oxc (not including the context-value) was restored. So I wondered I had to enter the value again.
In Directory Opus 12.24 we have blocked the shell extension by default so you no longer have to.