Orca Slicer is opening bambusource.dll from bambustudio install

[julie777]

Describe the bug

I have both Orca and Bambu Studio installed. I wanted to try a new feature just release in BS so I downloaded and started the install. The install stopped because bambusource.dll was in use. Using Process Explorer I found that Orca slicer has bambusource.dll open from both its directory and from the BS directory.

3mf File for This Bug If it is related to slicing, please append the 3mf file. It could be extremely helpful to solve the issue.

To Reproduce Steps to reproduce the behavior

Expected behavior A clear and concise description of what you expected to happen.

Screenshots If applicable, add screenshots to help explain your problem.

Printer model

Desktop (please complete the following information):

• OS: Windows 10
• Version 1.6.2beta

[hliebscher]

OrcaSlicer need the plugins form Bambu is not Open Source

[julie777]

OrcaSlicer need the plugins form Bambu is not Open Source

Orca downloads them into its plugin directory, so use should be independent.

[github-actions[bot]]

GitHub bot: this issue is stale because it has been open for 90 days with no activity.

[github-actions[bot]]

GitHub bot: This issue was closed because it has been inactive for 7 days since being marked as stale.

[dmorris68]

Bumping this a year later.

I use both Orca and Bambu Studio slicers for different situations. Orca has more advanced features. Bambu sometimes gets a new feature first, and Maker World requires 3MFs from Bambu Studio. And one time I downloaded a 3MF from MW that wouldn't print correctly in Orca, surprisingly. So I really need to keep and use both.

They each have their own copy of BambuSource.dll -- binary identical, and same CLSID -- in their respective plugins folders that they try to use. I can choose No to the registration prompt on the "Using a BambuSource from a different install" dialog and the camera still works fine in both. Because they're the same DLL with the same CLSID, only one can be registered at a time. If I respond Yes to let Orca register the DLL, then BS will start throwing the same error. And vice-versa.

Since both are binary identical, I thought I might delete the one that's not registered, assuming the app will find the registered one. Unfortunately, it still sees that it's missing from its own plugins folder and re-downloads it, putting us right back to where we started.

It's not a showstopper, but an annoying popup that I have to dismiss every time I use whichever slicer that didn't register the DLL.

I've looked through the code and found the offending section starting at src/slic3r/GUI/wxMediaCtrl2.cpp, in the wxMediaCtrl2::Load method. At line 136 it checks the path of the registered DLL against its own plugins path, and if it's not the same, it throws the error.

I can see a couple of ways to address this in the code. One might be to use a unique CLSID for each slicer's DLL, then both could be registered and used. Another would be to save the user's response to the prompt and suppress this error in the future, allowing it to continue using the other's registered DLL. (which works fine).

I would look at making the change myself and submitting a PR, but it's been ages since I've had a C++ compiler installed with Boost and WxWidgets and the other dependencies I expect I'll need. I guess if the maintainers don't care to try, I may give it a shot. But thought I'd ask.