TaskBarLayout now catches exceptions recording the taskbar location and handles them properly. It will skip any screenss that it cannot access the taskbar information for. The Screen layout generator for NVIDIA, AMD and Windows have all been updated to handle having no taskbar layout information (it just assumes the taskbar is down the bottom of the screen).
Hopefully fixes#114
There was a flaw in the way that ProgramSettings was being used that meant there was a lot of reloading and saving going on which was unnecessary. Additionally there were some errors in the way that the Settings file was upgraded which mean that the old settings were keeping on getting overwritten. Fixes#104.
Made some adjustments to when the MainForm is loaded, and how the NotifyIcon works for system tray.
Also Adjusted the way that the Windows Screens are computed so that we can reuse some of the code in AMD and NVIDIA screen generation so that the additional non-NVIDIA and non-AMD connected screens are still shown.
This will ensure that all screens show up in the images even if they aren't connected through an NVIDIA device. I also made the same changes to the AMD mode.
This is a subtle error, caused by either the NVIDIA driver being slow, or windows being slow in updating the location of the windows taskbar edge. This was causing an error in the GetNVIDIASCreenPositions function. Have added a 0.5 second delay to allow windows to update iit's display layout before we try to read it which should help, and also if we can't find the taskbar location in the settings, we just assume it is at the bottom. This should avoid exception.
Added specific checks to find and alert on 0 width or 0 height screens. This will then break other parts of the display layout.
Also moved the cloned screen check higher up to ensure we skip them properly.
Had some mistakes in the way that the profile graphics images were calculated on NVIDIA video cards. This meant that in some situations it calculated the image structures incorrectly, and didn't put the displays in the right places. This now changes that fact.
There is still an outstanding issue that the GetNVIDIAScreenPositions function still doesn't put the taskbar location in the right place yet. I need to fix that tomorrow.
I have been attempting to force Windows to refresh the notification tray using various Win32 API methods by sending messages to those notification tray windows to get them to refresh, but I haven't been able to get the right combination of setings. I am now leaving it for the next littlw while to concentrate on other issues.
There was a bug in the way that NVIDIA screen layouts were calculated. This error was due to a misunderstanding from me on how additional screens were listed within a mosaic config. Turns out additional screens are still recorded in the mosaic config, only just as 1x1 display grids. The screen finding logic now takes this into account.
Partially through a different refactor to completely change how the taskbar settigns are stored, and the logic behind the application. Should make the taskbar more robust to apply.
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.
This corrects some errors with the WinLibrary and how it handles cloned displays.
Also removed the 0.5 second delay between the end of the NVIDIALibrary call, and the start of the WinLibrary one, because they do not appear to be needed based on the NVIDIALibrary testing we've been doing with NVIDIAInfo.
Also corrected some log entries and comments.
I *think* that NVIDIA Surround and AMD Eyefinity changes are so great that WinLibrary gets confused and gives up. NVIDIA Surround and AMD Eyefinity affects the windows display layout so much. This change adds a windows config refresh after the NVIDIA or AMD config is applied to make sure that the winLibrary calls are using the latest updated active config that results from the NVIDIALibrary and AMDLibrary config changes.
Found some calls that were bypassing the video library state buffering I'd put in place earlier. This should generally make DisplayMagician faster and minimise the number of log entries written to DisplayMagician.log.
The profile updating logic wouldn't work with the new way of buffering the display config, which means that when swapping back to DisplayMagician after updating the display layout wouldn't automatically update the display profile. Now, it forces this.
Changed Profiles to use new methods for profiles detection provided by the new video card library updates for NVIDIALibrary, AMDLibrary and WinLibrary. This should make DisplayMagician faster as there is less repetition.
Weird error where having a clone causes an extra 'zeroed out' entry in the Windows Display Modes sequence. This change modifies the Windows mode info checks to allow for this situation.
Updated the profile so that it applies the new split video application process properly to DisplayMagician profiles. Should fix#45 (we shall soon see).
AMD Eyefinity now works just as well as the NVIDIA implementation... probably even more robustly than the NVIDIA one. Fixes#37 and #21. I'll now start on some other bugfixing and features in preparation for DisplayMagician v2.0.0
There was a problem with the unused display config containing null values on save, which meant that the JSON would be invalid when loaded in the next time. The fix was to ensure that both NVIDIA and AMD both were filled with a default config when a new profiles was created. This means that the real config would overwrite whichever config was needed, and the JSON file would work as all objects were populated correctly!
This is the first actual working version of the AMDLibrary from AMDInfo v1.0.0. This is the first time that all 3 different video libraries are in DisplayMagician and working (mostly). The AMD Screens structu creation logic in ProfileItem still needs to be updated to cope with the AMD Eyefinity configuration, but it at least defaults to the windows one at the moment so it doesn't crash (whew).
Also managed to bugfix the recent libraryfolder.vdf parsing change that a recent Steam Library change oforced on us. The logic wasn't working, and so the parsing didn't work, which in turn caused an exception when it came time to look up the game shortcut validity.
Issue when creating screens structure while NVIDIA setup is still partway through its changeover as it causes an exception. Now capture that exception and ignore it, as the screens structure is updated correctly when the screen finally settles down.
Windows changes the display source order which mucks up the equality matching in DM. This change attempts to mitigate that fact.
There were also errors in the HDR settings captured, which indicate that the HDR changes weren't finishing before they were being recorded. This change attempts to take care of that too.
All tests so far seem to work, so lets see how things go!
Mostly works now! Only bit still needing work is the Avtive profile detection to detect the non-surround profile when we return from surround. I think it's to do with the windows display number changing :(. I need to check that.
The derived ProfilteItem classes were an unnecessary distraction and wasted time I could be spending on other things. This set of changes are the first part of removing those derived classes and moving to a single ProfilItem class again, but with different configuration slots within it. Makes equality comparison SO MUCH EASIER!
I am a lot closer at the moment, but there is some bit of logic matching that is escaping me. I think I'm just too tired at the moment, and I need a sleep. I bet this will seem simple in the morning.
This (hopefully) should fix#38. Big thanks to @DragRedSim for their help. This will attempt to use the new library file liocation if it's available, and will fall back to the older config.vdf discovery mechanism if it doesn't find the new file.
Found an underlying problem of using the OutputID for displayIdentifier matching as the outputID changes after each reboot. CHanged the DisplayIdentifier to record the type of the connection to the display, which stays the same even if the OututID changes. Also made the ProfileItem.Equals look for DisplayIdentifier ids and match them even if they are in a different order. This seems to happen some times, and I'm not sure why the NVIDIA driver does it!
