Helo, I use Insync like Google Drive client. Problem is that when right click on folder / to get share link from Insync / Its not open from Opus windows to get share link. On windows explorer all is working fine. In atach sending what is open after right click, get link on windows explorer. On Opus this windows is not open. Please, if I can fix this problem.... Thank you
This may be something that you need to bring up with the makers of Insync, since Opus is asking their shell extension to run its menu item but their code then isn't doing anything for some reason.
They are probably expecting Opus to things in exactly the same way and same order that Explorer does and getting confused when something is slightly different. If so, we may be able to remove the difference between Opus and Explorer, but we don't have a good way to find out what it is that is tripping their code up, since we don't have their code. It should be easy for them to find, on the other hand.
This is not working for me either. I have been searching the web for a solution.
If anyone find a solution please share it here - it is really annoying. Seems to happen now and then with Directory Opus - its just not quite the same as Windows Explorer in the handling of context menus and icon overlays. Yes - MOST of the time it works great - but if your product mirrored Windows Explorer EXACTLY with respect to icon overlays and context menu's then there would never be an issue!
Fact is - I cannot live without Directory Opus so I push on - but these annoyances big me to no end. They interrupt my workflow when they happen, however rare.
Note: Total Commander works fine with Insync. I feel like this is a Directory Opus issue.
Note: XYPlorer works just fine as well.
I may be wrong but I have a feeling both those programs just ask the WIndows shell (Explorer, essentially) to show the menu, so it isn't surprising they work if the menu works in Explorer (which also isn't surprising, as Explorer is the one and only thing most people test their code against) and it does not indicate that the problem is (or isn't) with Opus.
The problem still needs to be brought to the attention of the Insync authors as the best people to debug it at the point of failure. If they find Opus is not sending them the correct information then we can look into that, but we have no way of knowing what difference in Opus is causing the problem in their code.
Has anyone done this?
[quote="leo"]I may be wrong but I have a feeling both those programs just ask the WIndows shell (Explorer, essentially) to show the menu, so it isn't surprising they work if the menu works in Explorer (which also isn't surprising, as Explorer is the one and only thing most people test their code against) and it does not indicate that the problem is (or isn't) with Opus.
The problem still needs to be brought to the attention of the Insync authors as the best people to debug it at the point of failure. If they find Opus is not sending them the correct information then we can look into that, but we have no way of knowing what difference in Opus is causing the problem in their code.
Has anyone done this?[/quote]
I have requested this and the statement from Insync is "We support Windows Explorer". I love Dopus, don't get me wrong. It is still incredibly useful for me. But. It seems to me GPSoft is passing the buck - they know they are handling these clicks differently than Windows Explorer, yet they say "well, tells us what's wrong". GPSOFT is best positioned to examine their own code and determine what is different between asking Windows Explorer to handle the click and how THEY are asking Dopus to handle the click. The answer from Insync seems fair to me "we expect the input to be compatible with Windows Explorer".
I guess I just don't understand why the onus is not on GPSOFT, and I am sorry for not understanding this, I am not trying to argue.
I am now using XYPlorer as I had a lifetime license sitting around - now they have a solution for 64-bit software context menus I am going to be using it until Insync works in Dopus. Don't want to switch but right now I do a lot of file sharing with Insync.
My understanding is that you can see their item in the context menu and you can click on it, but then nothing happens.
If that is correct, then Opus is showing their menu item and invoking it, and then it is not doing anything. (If that is incorrect, please let me know as I have not understood the issue until now.)
Once Opus asks their context menu handler to do something, what happens is up to their code.
Hi - but what you are missing is: this works with Explorer, Total Commander, XYPlorer, etc - Insync is expecting the the input in precisely the way these other tools provide it. Dopus is doing "something" different. Can we not request Dopus to determine "what" is different? I still believe the Insync answer is a fair answer - we work with Explorer and any other apps that are compatible with Explorer.
What you are missing is that those other programs rely on Explorer to display their context menu. So the reality is that Insync has been written to only work with Explorer.
This seems like a fair answer to me as long as they don't mind missing out on potential customers. If I needed sync software, I wouldn't even consider Insync now. Their loss I'd say...
We aim to make Opus compatible with Explorer, but obviously making it 100% compatible is impossible as some of the details of what Explorer does are undocumented. Even Explorer itself changes those undocumented details between versions, so different versions of Explorer are not really 100% compatible with each other, if we are talking about things at this level.
If something incorrectly depends on undocumented details of how Explorer behaves, then it might go wrong, either with Opus or with future versions of Windows that behave slightly differently.
For example, some software may assume that Explorer will look for certain COM interfaces in a certain order, and if the interfaces are requested in a different order (which the rules of COM explicitly say should not matter), the software may not work properly.
Now, although things like that are not meant to matter and would be a bug in other software, if someone finds such a thing and tells us about it then we'll probably change Opus anyway, since we want to be as similar to Explorer as possible, even where it shouldn't technically be required. But we cannot always find those minor differences ourselves. If the actual problem is in someone else's code, then it is up to them to locate the problem. We can then add a workaround if it makes sense.
We don't actually care whose code is at fault. We will often make changes to Opus to fix problems even if they are errors in someone else's code. But we can't find errors in other people's code, unless the code is open source or given to us to work with.
It's also possible that Opus is doing something incorrectly on its side, but since almost every other shell extension works fine with Opus it must be something very obscure. If Opus is passing data that is subtly wrong in some way, and that is causing the other company's shell extension to fall over for some reason, they are still the best/only people who can diagnose the problem.
It should only take a few minutes to install Opus on a development machine, attach a debugger, set a breakpoint in the shell extension code, and then right-click a file and see where things go wrong in the shell extension code. We'd do it if we had the code, but we don't have it, so we can't. If the people who wrote the code don't want to go to the effort of doing that then there is not much we can do.
I have confirmed that Opus is loading the Insync shell extension, and the shell extension DLL runs some of its code inside the Opus process, and also seems to trigger two threads to run very briefly in the Insync process:
So Opus appears to be trying to invoke Insync's code, and then something is going wrong within that code. Since we do not have their code, and since most other shell extensions work without issues, that is as far as we can take things on our side. The rest is up to the Insync team, if they care. If they don't care then it's not something we can do anything about.
Thank you very much for the explanation. I doubt they will resolve it based on their responses to my mails "we work with explorer".
Thank you for taking the time to explain this in such detail, it is very much appreciated. I have gone to using DoPus for everyday tasks and when I need to share files with using InSync I then switch to a competing product.
Thanks again - maybe one day Google will fix their program to allow managing more than one google drive account.