Closed thewavelength closed 4 years ago
I figured out something interesting... This bug only occurs when config.json
exists. Deleting it and restarting MaxTo will make it work as long as the process is running.
Something is really weird here. Doing the following:
config.json
presentconfig.json
Highlight region
Results in: Highlight region
ingredient only shows one big region even though MaxTo still works with three regions (and the region selector showing it as well) because I didn't start MaxTo when config.json was existing.
@thewavelength config.json
doesn't actually store your active regions, those are stored in a subfolder called monitor
, and saved in separate files per monitor. The file names vary based on the monitor identification you have selected. Are these files being saved with the correct region? (The file you attached has the "Quarters" preset saved)
I will try to investigate this, but having just this week set up a new ultrawide monitor myself, almost exactly in the manner you describe, MaxTo worked fine.
subfolder called
monitor
, and saved in separate files per monitor.
That's why I attached my monitor file :)
Are these files being saved with the correct region?
Yes, as soon as I click Use region
the file is updated.
The file you attached has the "Quarters" preset saved
Yep, that's the last region I have used for testing.
MaxTo worked fine.
MaxTo 2.0.1 worked fine as well. But the 2.1.0-alpha2 doesn't. Something in there must have changed.
What makes me especially curious is why the same bug happens on two different systems.
Is there something more I can do to debug this? Would a video help? Or something else? I really want to use the 2.1.x version because of the Recipe triggers, but currently really can't.
My last idea what could be a big difference between my systems and your setup is the use of a debloat script for Windows 10. I'm using a modified configuration file for that script. Of course I know you can't investigate random scripts from the internet. As you developed MaxTo, maybe going quickly through the configuration file of that script would show you if some setting name/identifier there could affect the behaviour of MaxTo.
I am going to need some time trying to debug this. I don' think it is related to your script, however there could be a lot going on behind those seemingly simple commands, and investigating this would be quite difficult.
Using alpha3 does not fix the problem.
I discovered another behaviour: when opening the region selector and trying to click on the "Use regions" button, nothing happens. The button gets it's clicked state but the region selector stays open and the region is not applied. Only way to exit that windows is clicking "Cancel changes".
Sadly, I still didn't find the common source for these types of bugs.
Just for the record: 2.0.1 is still working fine.
This sounds very strange to me. Are you using any software or mouse drivers that could in any way disturb mouse clicks? Can you try to set focus to the button and pressing space bar or enter to see if it activates then?
I don't. Space or Enter doesn't do the trick, sadly. In 2.0.1, it also works with Space then.
I can debug .NET applications on my local machine. If you let me know which function it is I could set a breakpoint on the function which gets fired when I'm pressing the button "Use regions" or the function which should be fired when pressing a hotkey to select a region and try having a look.
I have determined what makes the button not respond. If the Core process of MaxTo is not running when you click the button, the UI process will wait for a response from the core process forever before closing the windows.
I will have to do multiple things here:
I am 99% sure that I found the cause of this issue. When connecting to a VPN (or other network status events), MaxTo would try to get the name of the network you connected to. MaxTo uses the network name to allow filtering the network triggers. This caused an access violation (I don't know why exactly), which would crash the MaxTo.Core process immediately, with just a trace in the logs saying the MaxTo.Server process lost contact with one of the other processes.
I have fixed this for beta.2 by dropping support for filtering on network names (you can still filter on adapter name).
Can you confirm that MaxTo.Core.exe
is running immediately before a change in network status, and is no longer running a few seconds afterwards @thewavelength? That would give me greater confidence that I solved this issue.
Also, this is probably the same issue as #557.
Shall I download the latest beta somewhere or use alpha2?
Nevertheless I'd really wonder if this is the reason. I can't think of any network change when starting MaxTo after my system has been booted. I will still try, though it can take some days.
I haven't published the new beta yet, there are still some bugs I want to check out. However, if you can verify that MaxTo.Core.exe
isn't running when this problem appears, that would go a long way.
I can confirm two different behaviours running alpha3.
Scenario 1 (first run since months)
Scenario 2
I tried it several times and more or less it seems to be a bit random when MaxTo.Core.exe is crashing. On my third try, it crashed without me changing my adapter settings. Maybe I didn't wait long enough and got a new IP assigned which is also considered a network event.
tl;dr: even in the scenario where MaxTo.Core.exe keeps running, no regions work as expected.
I tried it again with 2.1.0-beta1. I can confirm the network bug still persists but all the other weird behaviours seem to be fixed! This is great news to me. So, from my previous comment, Scenario 1 now works as expected.
OK, I believe that this issue is then resolved in 2.1.0-beta.2. :)
Describe the bug Applying a region seems to work in the region selector but won't really be active when
config.json
exists. Everything is written correctly to the config files. Still windows will not snap into regions and can't be moved even with the default hotkeys. Applying a recipe with Highlight regions ingredient shows only one big region covering the whole screen, doesn't matter which preset I have loaded. After closing and reopening MaxTo, the region select still shows the correct loaded preset. It seems like something internally doesn't care about what the region selector thinks is active.To Reproduce Steps to reproduce the behavior:
config.json
will be written (see #520)Expected behavior Should work.
System information:
Additional context MaxTo-clean.log 5KC0391L08TL.json.log
I tested this on two different machines with the same system configuration. Same behaviour. Worked well with the same system configuration in 2.0.1.