Added some checks to temporarily pause any 'getconfig' type activities while we're changing the displayconfig. This should result in less config corruption, and fewer errors when there are timing edge cases.
We are able to patch the taskbar settings in DisplayProfiles without needing to get the users to remake their display proifiles. This changes the messaging to users.
This changes *should* be the last ones needed to get taskbar setting integrated. Fixes#78 (as much as we can fix it).
Works on Win 10, and partially on Win 11. Win11 won't update the main window until explorer.exe is restarted :(. There is talk that an upcoming Win 11 update will change that behaviour.
This change makes the ProfileRepository handle loading json config files from later versions of DM without causing an exception. This will mean that you can install later model config files and still have them work ok.
Used some of Soroush Falahati's amazing code, and now have the potential for storing the taskbar display layout. This unfortunately requires a display config change, so I will need to engineer some backwards compatibility.
The NVIDIA HDR colour logic was flawed, and wouldn't always apply properly. These logic changes now set the NVIDIA HDR colour back to windows controlled each time so the settings are at a known inital logical state. Then winlibray can set the windows HDR mode, and NVIDIA can set the NVIDIA HDR mode.
Since I multithreaded DIsplayMagician the Windows toasts don't work when DM is installed (they work when testing as I use another mechanism for that). This was my first session trying to troubleshoot that.
Found that I was combining Threads and Tasks together...never a good idea. Have moved fully over to a Task based model. Now still having issues with parallelism.
Updated the installer so that windows update is only forced to restart if it needs to be.
Added log rolling to DisplayMagician so that it keeps the last 4 log files as well as the one currently in use. Also updated the support ZIP file creation logic to include those extra log files so I can see exactly what's been going on, as well as added in the DisplayProfiles_2.0.json as well which I'd missed previously.
This is an attempt to avoid any potential non-thread safe UI updates to keep DisplayMagician as stable as possible. Moving to a thread-based model means that I need to be a bit more aware of the thread safe practices and attempt to avoid unsafe operations.
This is being done as the current UI code expects the shortcuts to block. This will be changed in the future when we move to .net6 and MAUI
Also fixed a bug I discovered with the stop program still being started if the user disabled it. And added in checking for the stop prgrams existence.
This ensures that all pathways to run a shortcut are covered by the protection of only allowing one profile change or shortcut run at a time. This will ensure that the single instance doesn't end up with multiple runs occurring at the same time and race conditions happening.
The stop program wasn't actually able to be stopped through the GUI due to the fact I missed updating the save and load functions to store that information :/. This has now been rectified.
Added SemaphoreSlim control to make sure that only one task at a time can be run. If any other task (Display Profile change or a Game Shortcut run) is attempted, it is silently ignored by DisplayMagician. This code then means that only a single instance of DisplayMagician is loaded.
Also found a bug in the StopProcess function that was stopping processes from properly being stopped. This has now been corrected, and fixes#75
Works fine, but still locks the UI. There is the potential for a race condition now as we have multiple pathways to run a shortcut or change the display profile. Next step is to stop that from being a problem.
Now instead of needing to be specified within the main Program file, we now have something that is defined and run from the SingleInstance class. I'll be adding the code to actually handle the different commandline options shortly.
The code now starts a namedpipeserver if it's the first instance, and if it's the 2nd instances it sends the full command line as an array to the first instance to get it to perform the work.
