How to debug DependencyProperty.Unsetvalue errors when the InnerException is null

Question

I have a custom login usercontrol that has a normal textbox and a passwordbox.

Blend refuses to cooperate with the PasswordBox saying that "DP.UnsetValue" is not valid for PasswordChar property. However the project compiles and runs fine in Blend or in VS2010. The cider designer in VS2010 doesn't seem to mind the error because it actually renders my UserControl for design time configuration.

Normally when I get one of these errors there is an InnerException with a path to the file/resource missing. That's not the case here and I'm not sure how to figure out how to fix it for when this comes up in the future.

I swapped the tags to turn the PasswordBox into a normal TextBox and it seems to be fine with that. However I need the input masking that PasswordBox provides. It's not very practical to comment out that object and finish styling my control in Blend.

Here's my Xaml:

 <PasswordBox x:Name="PasswordTextbox" PasswordChar="*" Height="26" VerticalAlignment="Center" Grid.Column="1" Grid.Row="1" Margin="5" RenderTransformOrigin="0.5,0.5" TabIndex="3">
                <PasswordBox.RenderTransform>
                    <TransformGroup>
                        <ScaleTransform/>
                    </TransformGroup>
                </PasswordBox.RenderTransform>
                <PasswordBox.Effect>
                    <DropShadowEffect />
                </PasswordBox.Effect>
                <PasswordBox.Triggers>
                    <EventTrigger RoutedEvent="UIElement.GotFocus">
                        <BeginStoryboard Storyboard="{StaticResource StoryboardScaleUpFontIncrease}"/>
                    </EventTrigger>
                    <EventTrigger RoutedEvent="UIElement.LostFocus">
                        <BeginStoryboard Storyboard="{DynamicResource StoryboardScaleNormalFontNormal}"/>
                    </EventTrigger>
                </PasswordBox.Triggers>
            </PasswordBox>

Does anyone know how to debug this behavior?

Solution 1

I was finally able to solve this issue by using the techniques described on this blog entry:

http://web.archive.org/web/20090602111317/http://bea.stollnitz.com/blog/?p=52

Solution 2

I also had the same issue in xaml designer but in a sightly different way. I add the detail here in case it is helpful to someone.

I was using a 3rd party control which has their own theme defined in a dll. I referenced this dll and use 'StaticResource' to reference some resources defined in that dll. Then the xaml designer underlined my xaml code saying something like 'D.Unset is not a valid value for xxx'. But the program compile and run without any problem.

To eliminate these annoying underline, the solution is simple: Change 'StaticResource' to 'DynamicResource'. Another more complicated way is to use 'ResourceDictionary.MergedDictionaries' to include resources in that dll into your xaml file.

Solution 3

I advice to recheck (twice or more) your ResourceDictionary. I came to this error after I added to my ResourceDictionary:

<Style TargetType="Label" x:Key="myLabel">
    <Setter Property="Foreground" Value="{StaticResource myDefinedColor}"/>
    ...
</Style>

while {StaticResource myDefinedColor} was defined BELOW it. In my case error was about Foreground that has UnsetValue. So actually it really was an unset value... I moved my style for Label below defining my color and that was it!

Solution 4

Just wanted to add that this was helpful in solving an issue for getting a "DependencyProperty.UnsetValue is not a valid value for property" error solved, in particular the first part of the blog suggesting that your resource might not be valid (i.e. previously defined and available for use). Turns out in my case it was the classic issue of not defining my resources in the right scope and before they are actually called upon.

My advice: First look to make sure you define the StaticResource in the appropriate Element.Resources section. Make sure that definition is physically located before your actual call to the resource.

Solution 5

Seems an old post. I solved my issue by putting the stuff in order of use in resourceDictionnary merging. In the example below, I called the resource 'Couleur.xaml' later and i had the error message. So I put it in first place and it solved my problem:

    <ResourceDictionary.MergedDictionaries>
                <ResourceDictionary Source="/TS;component/Ressources/Couleur.xaml"/>
                <ResourceDictionary Source="/TS;component/Ressources/ButtonStyle.xaml"/>
                <ResourceDictionary Source="/TS;component/Ressources/DataGridStyle.xaml"/>
            </ResourceDictionary.MergedDictionaries>

Hope it's gonna help somebody out there!

View more solutions

Comments

[Dr. Andrew Burnett-Thompson]

Turns out in my case the default style for a WPF type was setting a property "Foreground" with a static resource that wasn't defined.

[TWood]

I've definitely fought this problem too. I now scope as narrow as possible while developing and testing and slowly move things out to dictionaries once they are proven out. This has resulted in me getting less of these errors, but it does take longer to maintain.

[isakavis]

I had similar this error in a PRISM application for error template. Just by changing StaticResource to Dynamic solved my problem.

[Luuk]

Note that static resources are changed compile time, and dynamic resources are set runtime, so there is a slight performance impact

[code4life]

Sorry to reopen this post, but your comment Another more complicated way is to use 'ResourceDictionary.MergedDictionaries' is inaccurate. It's not complicated at all - it's just a single line and you just have to understand the specific syntax for specifying a file that resides in a DLL (aka resource). Also, DynamicResource specifies a particular usage that is different from a StaticResource. You have to understand the performance cost that will be incurred before liberally using DynamicResource in your project.

[Ed Bayiates]

This was the only thing that helped. The same tracing that works on data binding can also be configured to emit tracing on WPF resource failures.