Updated the NLog exception handling to make use of the additional logging options released recently. This will help provide me with more details when users create the Support ZIP File.
This is required so that the undocumented DISPLAYCONFIG_SOURCE_DPI_SCALE_GET Windows CCD call is given the correct information by Windows 10/11. It gives an abnormal number on some hardware if this is not set. What we do now is set the process DPI context to "System Aware" on boot, but when we are either getting or setting the Windows DPI settings, we quickly swap to "Monitor Aware v2" DPI context, before swapping back to "System Aware" when we're done. This *should* return the correct per monitor settings.
The NVAPI and Windows APIs were checked multiple times in a row due to a logic error. THis has been partially corrected, but needs a lot of work to straighten it out.
This function isn't needed, but seems to be unreliable when it's used. So diabling it within NVIDIALibrary to reduce the chances of there being memory errors thrown.
There is a possibility that there are two displays with the same UID. This happens with software created displays such as SpaceDesk and Superdisplay. This means that we need to try and figure out which screen is the right screen, and then when we know which screen we were really wanting to
The NVIDIA Driver seems to not like any other SetTopoFlags except NONE. There is a CTD if anything is selected :(. So as a workaround I will leave send a NONE SetTopoFlag so DisplayMagician can work.
Also have updated the Display Profiles Window logic so that it repositions DisplayMagician in the center of the screen on the primary display. This has to be done when changing Display Profiles using the Apply Button, as the display coordinates change, and sometimes this results in the current position being off screen. This was causing confusion amongst users. But now just always moving to the middle of the primary screen I can always be sure that the UI is visible.
NVIDIALibrary and WinLibrary were too rigid in their equality testing, which meant that there was a problem when Windows reordered the displays in the path. This happens randomly when changing to cloned displays, and after a reboot. This would muck up the equality testing, which would prevent users selecting the display profiles. This has now been corrected (as far as we can tell so far).
There is a slight chance that further testing may find other parts of the Windows Display Config that randomly change and need to be updated. Thanks Microsoft.
DM will now warn users they will need to recreate their Display Profiles again. I really hope this is the last time I have to do this to my lovely users.
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
This was a major error that somehow slipped through previous work. WinLibrary was only partially patching the Windows Display Config when it was being loaded, and that resulted in some parts of the Windows Display Config not working after a windows reboot. This should now be fixed!
Fixes#103
IMPORTANT: This patching means that DisplayMagician is able to use your existing Display Profiles, but there is a catch! DisplayMagician won't be able to detect that your old profiles are currently in use... in other words DisplayMagician will constantly think that you have a new Display Profile until you save a copy of the DisplayProfile again.
This occurs because DisplayMagician now gets and compares the NVIDIA 3D Settings and there is no way for us to figure out what previous 3D settings were in use when you set up previous display profiles. For that reason we'll just need you to save new Display Profiles.
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.
This DRS Support is just reserving a space for the future addition of DRS Settings pulled from the driver. This will allow the recording of settings listed in the 3D Settings within the NVIDIA Control panel.
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.
There were some issues with memory deallocation where AllocateHGlobal memory was being freed incorrectly with FreeCoTaskMem. This was causing issues with subsequent memory allocations.
