Hi
Yes, it's the 3rd step. It works on some PCs, and fails on the others.
Is dopusrt.exe the API you mentioned before?
Opus has an API which software can use to ask it which files are selected
I mean, do we have any other way to get the selected file without reading/writting file?
Seer needs to track the selected file frequently, it would be great if we have anything without file operation.
Thank you~~
If you can't get Seer Pro to work with Opus on Win10, try QuickLook for Windows instead.
It has the same functionality and does work on Win10 (tested with v3.6.5; v3.7.1 is the current version)
Testing is easy as ther is a portable version too (make sure Seer Pro is not running at the same time)
QuickLook is free and open source.
Fails in what sense?
- The exe isn't found?
- There's no output file?
- There is an output file but it's not containing the expected data?
As I checked the log file from spier, it is exe not found. But he can run the command in my code successfully in CMD window. Also the same Seer.exe works well in my test env in virtual machine.
+1 will probably buy this software if it worked with Dopus
1 Like
I don't know how Seer currently locates the exe, but there are a couple of ways you can do it:
-
FindWindow("DOpus.ParentWindow", NULL)and then useGetWindowThreadProcessIdetc. to get the path toDOpus.exeand change the filename part toDOpusRT.exe(they'll always be in the same folder). -
On a HDD install of Opus, you can also lookup the path in the registry, but that won't work with a portable install.
Using the window method probably makes most sense for something that reacts to a keypress in the Opus window, since you know Opus is running in that case.
The main advantage of the registry method is that it'll work when Opus isn't running, but that isn't useful here. However, for completeness, the registry data is here:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\DOpus.exe
Is Opus running elevated? UIPI can prevent those programs from 'talking to ecah other'
Or dopusrt.exe, running as a regular user, is unable to 'talk to' dopus.exe as that is running elevated.
(all untested; just trying to help ... )
I've switched to Seer from QuickLook. It is not responsive and freezes frequently.
Problem solved by other method.
Thanks.
1 Like
might you share what other method was? it may help others
1 Like
The latest version 2.8.4 works well on Windows 10. http://1218.io/seer/dl
@Corey Thanks so much for the update!
1 Like
Still not working here after downloading Seer-2.8.4 fyi
Tried with 2.8.4; still not working.
It has something to do with the Administration access.
Seer has to have the exact same privilege with dopus.exe.
A straightforward way to run them with same privilege is to open Seer's installation folder, then double click Seer.exe to run.
Here is what I found. @Leo
Everytime you start the main process, dopus.exe, it runs the helper process, dopusrt.exe, with same privilege.
When you quit dopus.exe, dopusrt.exe is still running in the background. The next time you start the main process with different privilege, dopus.exe and dopusrt.exe will have different privilege. This is the case dopusrt.exe stops working.
Even if the dopusrt.exe has Admin privilege and dopus.exe hasn't, it still doesn't work.
Running Opus elevated should be avoided as it causes problems exactly like that, many of which are unavoidable due to how to the Windows APIs we have to work with behave.
Instead, people can use Opus's UAC support, which includes the ability to elevate a window and keep it elevated, without elevating the whole process.
Why it's also not working when Seer is evaluated and DOpus is not? It makes things complicated for users.
The API I called is createprocess. I can send you my DOpus.cpp if you need.
If you run DOpusRT elevated when Opus isn’t elevated, DOpusRT will be able to talk to Opus but Opus won’t be able to send results back to it. (If it’s the other way around then the problem is the opposite.)
DOpusRT should be run at the same elevation level that Opus is at, which in turn should (almost always) be the same level the Windows shell (explorer.exe) is at, i.e. unelevated.
DOpusRT has a /runstd mode you can use to run any command unelevated, so you could use that on itself to drop elevation if needed:
https://www.gpsoft.com.au/help/opus12/index.html#!Documents/DOpusRT_Reference.htm
We use that in our installer to launch Opus, but it’s also there as a general utility since it’s otherwise quite hard to run things unelevated from something that is elevated. (It’s like Microsoft didn’t think of it when designing UAC.)
1 Like
Makes sense now. Looks like I have done everything I can to be compatible with Dopus.
Thanks.