strange wpf xaml problems when using libz

Mar 13, 2014 at 2:53 PM
Edited Mar 13, 2014 at 2:56 PM
hi krashan,

first of all thanks for your great tool, helps us a lot.

i just stumbled upon a weird bug: in a xaml i set some of wpf's datagrid colors:
   <SolidColorBrush x:Key="{x:Static SystemColors.InactiveSelectionHighlightTextBrushKey}" 
  • when not using libz, the datagrid displays correctly when the application is started with and without debugger attached (both debug build though).
  • when using libz, the datagrid displays correctly when started with attached debugger, but when started without not only the brushes of the key above are affected: deselected rows also have white text when only the selected ones should.
  • when not using libz and removing the custom color section from xaml it correctly shows the standard system colors.
  • when using libz and removing the custom color section from xaml it also works correctly.
i guess this is not a libz problem per se, but i this is my only clue so far :)

any idea/thoughts?

Mar 13, 2014 at 2:58 PM
Edited Mar 13, 2014 at 3:00 PM
I have no idea. Some useful information would be:
  • Enable tracing and check what assemblies are actually loaded. Does it load the ones you would expect?
  • Check if same thing happens when targeting .NET 4 and .NET 4.5
  • Write console application returning (int)SystemColor.XXX and run it with libz and without?
  • Is there any other SystemColor in any other assembly?
Mar 13, 2014 at 3:12 PM
thanks for the fast reply!

after posting i immediately started to look into the typeof(SystemColors).Assembly. i just logged the Assembly.FullName and it's the same in all cases. i wonder if i can rely on that FullName string?

of course the problem can arise from another assembly misinterpreting the given key for the color. is there maybe some way to compare the loaded assemblies? other than manually i mean of course :)
Mar 13, 2014 at 3:29 PM
Maybe it gets resolved differently when resolved from code and resolved from XAML.
Can you actually go thought those resources and log actual Key values.
Mar 13, 2014 at 3:51 PM
oh man, how i hate stuff like this.

i had a look around and did some changes here and there. now the (imho) wrong colors showed up also when the debugger was attached. of course i'm not able to trace back my steps.. :/

so i just removed the custom color and have to live without it for now. at least the same assemblies now load regardless of debugging, hooray for (some) consistency!
still, the problem remains only when using libz.

i would have liked to investigate further but time is running out right now.

do you have some advice on how to output the loaded assemblies without a debugger? my (maybe stupid) way would be adding a AppDomain.CurrentDomain.AssemblyLoaded event handler and logging that.

anyway, thanks and cheers
Mar 13, 2014 at 5:04 PM
Edited Mar 13, 2014 at 5:04 PM
Tracing has been addressed here:
It uses System.Diagnostics so whatever you configure will be used. If none, use free google://TraceTool it will show all messages from libz.