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.
Mainly based on Johan Larsson Gu.Wpf.SingleInstance and Novotnyllc SingleInstanceHelper code, extracting the various bits that make sense for DisplayMagician. Using a mutex, and System.Runtime.Remoting.Channels.Ipc
I redeveloped the help wiki at the guthub site, and took the opportunity to add some guidance to the different UI windows that would be most helpful there. I also added a new 'Initial displaymagician setup' wiki page to help people just starting out.
Hopefully helps with #70
DisplayMagician can now run a Main Application, Start ptogram or Stop Program as Administrator (usin 'Runas') which will bring up a UAC prompt. Works fine for all three types of process stat, so will keep it there :)
Please note, there isn't any run as administrator fuctionality for the Games Launchers as they don't support that at all, and if I tried to add it, it would get really tricky really quickly. This functionality should suffice for 99% of use cases.
Changed the majority of the Shortcut loading code to be way more robust, and clearer to follow. The code had grown organically since the beginning of DisplayMagician, and really, really required some changes to make it all more robust and easier to make changes in the future. This is the first commit of that code so that I can ensure I have an offsite backup.
There is still a bit more of testing and bug hunting to do before I can be sure that it is all ready to release.
Fixes#68. The reason DisplayMagician was crashing was that it was hitting a Uplay Game in the Steam Library. This was not a valid thing to see. The reason DisplayMagician was doing that was because of a bug in the way that the list of installed games was combined. This bug has been in all 2.x versions of DisplayMagician, and would have affected anyone with Steam and any one more GameLibrary (e.g. GOG, Epic, Uplay etc).
I also managed to find a potential issue with editing shortcuts that I've hopefully now averted.
Properly clear out the form and all it's storage variables when the form loads (done)
Add in some protection logic to avoid a crash even if this situation occurs again (partly done)
Additionally, I found a recursive logic flaw that meant that DisplayMagician used WAAAAAAAAAAAAAY more memory than it needed to. I'm talking 5GB of memory rather than the 129MB it was supposed to do. So I'm so thankful that you logged this issue so I could find that one :).
Improved the minimum form sizes for multiple forms to stop them looking bad.
Updated the DisplayMagician and DisplayMagicianShared assembly versions to v2.1.2.0 in preparation for release as the next version of DisplayMagician.
