I think this is something IDM will have to change on its side.
It appears to be doing this:
- Open the folder by using ShellExecuteEx on the folder path with null verb. (Fine so far.)
- I assume it then tries to find the File Explorer window based on the window title/class and process, or something similar which would only apply to File Explorer and won't work if the folder opens in something else.
- After a while it seems to stop waiting for the File Explorer window to appear.
- It then runs explorer.exe with some arguments to ask it to select the file. Opus intercepts that, but the long delay has already happened due to IDM apparently waiting for a window to appear.
Basically, IDM is probably assuming File Explorer is what folders always open in, and if so needs to be changed.
Opus implements the COM API for finding File Explorer windows so things can find them via that. But the window titles/classes and process name obviously won't be the same for Opus and File Explorer, if those are being used instead.
The easiest fix for IDM would be for it to not do any of the above, and instead just call SHOpenFolderAndSelectItems, which is an API that exists for doing this exact thing. That API works with both Opus and File Explorer.
Alternatively, they could let you configure the command(s) to run to open folders and select files, so you could specify alternative file managers. That would require the user set things up manually, but would also work with more alternative file managers, since many don't handle SHOpenFolderAndSelectItems (which is quite complex to make work!).