How to get "Share" button/feature as in native File explorer?
If i select a file in native file explorer in windiws 11 i can press button "share" and share the file(s) to different apps. But this opiton is nopt in the Opus menu when double clicking a file nor can i find it in the menues
With the new Microsoft "Link to Windows" update allowing to share files from Android to PC and from PC to Android, this feature ("Share" feature in Directory Opus as in MS File Explorer) need has increased 10 times.
There must be a way to bypass th Microsoft design ?
I guess we could try to get a job at Microsoft, fix their code, then quit. Other than that, we don't know of any way to fix it, and they ignore all problem reports and couldn't care less about third-party software these days, so it is what it is.
Instead of going through the hassle of compiling the code, especially if you're unfamiliar with the process, there's also a pre-compiled version provided in the repo. I tried it, but it was a bit hit-and-miss; sometimes it worked, and sometimes it didn't. Also, since it was six years old, the .dll files were quite outdated compared to what we have for today's share menu.
You can add this to the context menu, or do what I did: I created a 'Share' button at the top toolbar in Directory Opus or anywhere you'd like to have it. When clicked on after a file has been selected, it opens the Windows Share Dialog. In the command section of the button, input this: the_location_of_the_complete_path_of_the_file {allfilepath}
I totally get why you'd think that. It is counter-intuitive when the source code for the application is identical. But the key difference came down to the newer DLL files I used during compilation.
Even though the core code didn't change, those external DLLs often get crucial bug fixes, performance optimizations, and compatibility updates over the years, especially for features like 'Phone Link.'
From my experience, with the older DLLs, 'Phone Link' file sharing with android was incredibly buggy and inconsistent, a real hit or miss. (For other apps, it might have been fine, but I didn't test that.) However, when I compiled with the newer DLLs, file sharing became much more reliable and smoother with Phone Link.
So, while the application's code remained the same, the updated external components made a significant difference in how well that specific feature performed.
Unless the newer dll does contain symbols that were not in the original ones and you have some conditional branching inside the compiled code to use those symbols, the whole point of DLLs is that their inner code does not interfer in the compilation process. Meaning : you can compile source code A with old or new dll, the output product is the same (since it does not embed the dll code, unless you go through a tough process to somehow transform your dynamic library to a static one).
What can change is if your execution environment uses old or new DLLs, since, as the name indicates, they are linked at runtime (DLL = Dynamic-Link Library).
You're completely right, and thanks for the clarification. I was a little confused about the compile-time and runtime aspects. Upon reviewing the repo's instructions, I noticed that in addition to the .dll file—which does have the same version number—there's also a .winmd (Windows Metadata) file mentioned. That file actually has a different version number than the original. I mistakenly grouped them together. Honestly, I have no idea what a .winmd file is.