I'd made a revision to the Paths and Topologies
equality comparison and it used Equals for
sequences rather than SequenceEqual as it should.
Comparison works correctly now.
Fixed up some broken logic around detecting
loadedProfiles as the currentProfile. Now when
we load the profiles from disk we also correctly
check whether one of the profiles is in use now
and if it is then we use that profile instead of
creating a new one.
Added some logic to check if either the from or to
profile conatins an NVIDIA surround screen. If not,
then there is no need to apply a GridTopology as it
is all single devices! Saves up to 15 seconds on
swap over.
Was missing a SetTopologies command from upstream
and the latest GeForce devices don't seem to be able to
read EDID which means the Topologies dont have a
DisplayName peroperty, which in turn causes issues when
trying to change to that topology! So now detect empty
DisplayName and fill it with a default.
Fixed the WindowsDisplayAPI Device Identifcation
logic so that it reliably detects the displays in a way
that works when some displays are disabled as well
as when they are enabled. Also divided up the
DeviceIdentification into two separate functions so
that one will list all attached devices, and the other
will only report the devices currently in use.
DisplayUI is mostly working but it needs some work
fixing the error situations when the PathInfo can't be
applied properly. Need a way of setting the Task
result from the Task Action. Don't know how to do that
so something new to learn!
This code makes the display profile change work. There
are a few things broken still.... namely the showing of a
timer when the profile is being applied, the accuracy of
the display detection code, and the correct logic for
determining a profile can be used.
There are different displayIdentifiers created if the video card
is an NVidia card, or if it is anything else. These identifiers
are saved in the display profiles, and that allows us to compare
the display identifiers we currently have with the ones in various
profiles, and then work out which profiles are valid.
This code committed today ensures that the nvidia device
identifier will always use the NVAPIWrapper lib (whether in
surround mode or not) so that the application allows both
surround mode profiles and non-surround mode profiles
to be selected if the same displays are present.
For all other display adapters it just uses the
WindowsDisplayAPI to create a different displayIdentifier
which isn't as smart. It means that if you have an AMD and
use EyeInfinity, then this isn't clever enough to understand
the profiles use the same matching screens. I will have to
fix this eventually when i build in native AMD support in
the future.
The existing logic for detecting displays connected to
an NVidia device doesn't allow matching for Nvidia
surround and normal surroundless profiles. This means
that you cannot determine which profiles are the valid
for your display setup. This is testing the NVAPIWRapper
scanning and the WindowsDisplayAPI libraries to see what
information will work for tracking the screen in the profiles.
DisplayIdentifiers are the minimum GPU/Display
that will allow us to identify whether a profile
will actually work. We look for the same DisplayIdentifiers
or a subset of them to determine whether a profile
will be valid to show. This is different from the data
stored under DisplayTarget, as that is used for detailed
compatibility....
First part of installing an MSTest suite.
Included some config file to read in
for testing the ShortcutRepository and
the ProfileRepository. Had the data
handy so it made sense to save it :)
The IsPossible logic in the ProfileItem incorrectly
uses the ToPathTargetInfo, when a better match is
to look for all the actual displays that are currently
turned on, and then allow all profiles that include
only the displays that are turned on. That involves
1. getting a list of the display devicepaths, and then
2. checking if this profile has all the devicepaths
needed to show the profile. If it does, then it
IsPossible.
The ProfileAdapter and ShortcutAdapters used
by the ImageListView Control unfortunately
have to access the sizes of the bitmaps being
loaded into the respective imagelistviews. I
can't find anyway of stopping the GDI+
from complaining about the Bitmap being
accessed by multiple different threads (as
ImageListView creates one thread per image.
This will be fixed once I move to this being a
WPF application as we'll use a different control.
Profile selection logic was running functions multiple
times which was resulting in a lot of extra delay
while using the DisplayProfileFOrm. These changes
streamline it and make it work a lot faster!
Moved the shortcut running logic from the
main Program into the ShortcutRepository
so that it can be used from the
Shortcut Library UI as well as from the
commandline.
It's marked as WIP because I also moved
the ApplyingChangesForm and accompanying
ApplyTopos/ApplyProfiles logic and I broke
it. It needs refactoring and hopefully
simplifying but I need to work on that next!
Updated the 'Save To Desktop' button in the
ShortcutLibraryForm to use the CreateShortcut
function in the ShortcutItem, and fixed that so
it now uses the IWshRuntimeLibrary to create
a Windows Script Host that will create the
shortcut.
Did a fix for the SHortcutAdaptor doing exceptions
for showing the form before loading all the graphics
but can't really do much about it without adding
background loading to the main form. This is a lot of
work considering we'll be moving from WinForms
to WPF UI in the future.
Also fixed the 'Do you want to save' prompt detection
logic so that it correctly waits until all the loading has
finished before monitoring for users making changes.
Should stop the form incorrectly suggesting you
should save unless they've really made a change.
If a shortcut has Autoname turned on, and if the user
changes the name of the profile, then the shortcut will
be renamed to keep pace with the new profile name.
If autoname is NOT turned on, then the shortcut name
will be kept as is, and the user will need to make any
changes. Please note that HeliosPlus will not make
any changes to any desktop shortcuts saved to the PC.
It will only change the name of the shortcut in the
shortcut library within the App.
Moving to using a ProfileRespository will make it
easier when moving to a WPF style app, and it will
allow some freedom if I want to change the storage
to a database or soemthing different.
Partially completed bitmap work.
Need to implement generic bitmap
resizing to work with small and large
icons, and for different sizes for overlay
bitmap.
Created ShortcutRepository which handles
the loading/saving and lifecycle management
of shortcuts. There can only be one shortcut
repository at a time, hence it's mainly static
methods.
Also started down the path of troubleshooting
the profileIcon overlays. The ToBitmapOverlay
still isn't working properly, so I need to figure
out how it was working originally, and how I
broke it :). Then I need to unbreak it.
Still having issues with the shortcutAdaptor for the
Imagelistviewitem loading. Even though it's based
on the same code as the profileAdaptor it's not
reading the Shortcut bitmap properly. Too tired to
figure out why at the moment, so will be trying again
tomorrow. I expect its something to do with the
different Bitmap format for the two options. May
need to revise that to compare image data.
Have created the Shortcut class for use within the
ShortcutLibrary. Next step is modifying the
ShortcutForm to generate a Shortcut so that I
can check the loading and saving is working ok.
I won't concentrate on the ShortcutForm redesign
until this bit is tested.
Manged to get the ImageListView working directly
from the Bitmap stored in the Profile. This makes
the refresh of the ILV much faster, and makes it way
easier to use it in other UI forms.
