Open eikowagenknecht opened 2 years ago
At the very least as a workaround, the ability for MaxTo to not touch some apps would be needed. Like the Compatibility settings, but user defined.
Is this product supported any more?
I am also suffering from this problem, and would really appreciate if this could be looked into.
GPSoft, the developers of Directory Opus have a few threads on their support forum which go into some detail that may assist you in nailing this down.
https://resource.dopus.com/t/maxto-crashes-when-opening-image-files/40271/2
https://resource.dopus.com/t/crash-creating-folder-on-network-share-due-to-maxto-window-hook/29500/8
If required, I'd be willing to send over the crashdumps from Directory Opus if they would be useful to you in getting to the bottom of this.
Very disappointed about the support here, I switched to Microsoft Powertoys which is even better in some regards, free and does not crash! 👍
Unfortunately FancyZones within Microsoft's PowerToys isn't suitable for me, as it seems it lacks the functionality to immediately move a window to a particular position on the grid by keyboard shortcut.
I'm hoping that MaxTo devs can respond soon.
Yeah I think it can't do this. But setting the movement to relative position and then moving windows around with win + left/right/up/down works really good.
Defining a good set of overlapping zones needed quite some JSON editing as well, but I'm very content with the result.
I have so far not been able to reproduce this with MaxTo 2.2.1 and Directory Opus 12.26 on Windows 11 21H2 (22000.493).
I am running Windows 10 21H2 (19044.1526), and continues to affect me.
Again, I am more than willing to privately send over the crashlogs from Directory Opus if this will help.
Opus developer here.
Reproducing the problem is very easy:
After not very long, the process will be killed. Crash dumps suggest heap corruption or a callback DLL that has been unloaded.
It's quite frustrating that we are still getting users reporting this problem to us, and thinking it's a bug in Opus, which we then have to investigate only to find it's this issue that's still there. If we can help to fix it, please let us know. Or add Opus to the long list of other apps that MaxTo causes problems with and needs workarounds for. Up to you. Or if there is something we can do on our side to prevent the hook DLL being loaded into our process, we'd be happy to do that too.
Guessing about possible causes, our viewer window can resize itself while it is opening (to fit the image size, toolbars, etc. dynamically as the window opens). That could be confusing things. Some software with UI hooks also gets confused by Opus's multiple UI threads which talk to each other and sometimes have multiple UI threads for the same top-level window.
I'm just here to support this issue, love MaxTo love DOpus, let's get them to work together flawlessly!
Just to let you all know, we are very aware of this issue, and haven't been able to pin it down yet. Our regular compatibility shim method (which allows us to disable all MaxTo functionality for a given window) does not appear to work for DOpus.
Is there anything we can do/provide on the Opus side to help track things down? This issue is over a year old now. :(
Seems there is no desire to actually fix this, and you're happy for your software to make ours crash and look unstable for over a year now.
I've tried a few times to work out how to block your DLL or window hooks/subclassing from loading into our process, but haven't been able to work out a way.
Our only option now is to detect when the DLL is in our process and display a message to the user to warn them that MaxTo is known to crash other software and should be uninstalled, pointing to this bug report as evidence.
Seems there is no desire to actually fix this, and you're happy for your software to make ours crash and look unstable for over a year now.
I've tried a few times to work out how to block your DLL or window hooks/subclassing from loading into our process, but haven't been able to work out a way.
Our only option now is to detect when the DLL is in our process and display a message to the user to warn them that MaxTo is known to crash other software and should be uninstalled, pointing to this bug report as evidence.
I've been subscribed to this Issue for a while now but did not want to comment and add unnecessary noise.
I'm a Dopus user and have been affected by this issue as well. I use Dopus far more than I use MaxTo and had uninstalled MaxTo a while back to avoid the crashing issue.
Given the complete lack of updates on this thread, I'm glad I did that and am pretty sure I will never be installing the software again, despite having bought a MaxTo license to support the dev's in the past.
It seems like most issues stay open without any real fixes (apart from issues that can be closed as "read the docs"), perhaps the devs should update the README to state the software is no longer actively supported?
Describe the bug Having MaxTo enabled leads to two problems:
1) Directory Opus crashes on opening windows. Here is the analysis of the DOpus developer: https://resource.dopus.com/t/maxto-crashes-when-opening-image-files/40271
2) On Windows shutdown, errors similar to https://github.com/digitalcreations/MaxTo/issues/409 happen for various applications, e.g. Keepass and Citrix Workspace:
Maxto Log around that time:
It took me a very long time to rule out memory / hardware problems etc. and pinpoint this to MaxTo. Please fix this as having many crashes makes MaxTo unusable.
Screenshots For 1) see linked thread For 2)![image](https://user-images.githubusercontent.com/1475672/148760090-a2398a57-51b6-49fb-b407-79b56ac422f5.png)
System information: Windows 10 Version 21H2 Build 19044.1415, but also happens on Windows 11. MaxTo 2.2.1