2

In the code sample below returning Binding.DoNothing from the value converter still causes fallbackValue evaluation. Pay attention on context.

<Style>
<Setter Property="FontSize" Value="{Binding ActualHeight, RelativeSource={RelativeSource self}, Converter={...DoNothingReturningConverter...}/>

Binding.DoNothing documentation is clear about not using fallback value (though I am not 100% sure how to interpret 'for example'). Other answers on this topic assume as much.

Actually, fallback value evaluation is attempted in order to set expression value in the dependency property entry. This happens in different from converter part of control flow, when evaluated style is applied to the control.

I am looking for any additional information about this subtle DoNothing behavior. To my mind it is a bug in WPF 4.5, though it can be by design :-)

Community
  • 1
  • 1
Plavunez
  • 23
  • 2
  • 1
    Post more code. Tell us exactly what you trying. Tell us what you want to reach? Like the name says Binding.DoNothing is not doing anything so what exactly you mean with fallback value? You are not using fallback in the example binding you gave us. Keep in mind FontSize is a dependency property which supports inheritance and maybe it has its own validation internally. In wpf you can create a dependency property with coercing and validating logic. Also there might be alternative solutions if we know what you up to. – dev hedgehog Oct 06 '13 at 19:27
  • My problem is diagnostic messages emitted by WPF and also possible bug in WPF to report. Converter realizes y = x/2, so when ActualHeight is zero it produces invalid value for the FontSize. I could handle this situation by returning some other value, but I thought a better solution is to avoid transfer of value at all. This indeed is happening with DoNothing. However, some time later styling – Plavunez Oct 07 '13 at 18:09
  • However, some time later styling will try to retrieve binding fallback value and emit the information message (no fallback value obviously). So to my mind, DoNothing fails to achieve what is written in documentation. Either I can find a way to avoid a message, or I file a bug report. – Plavunez Oct 07 '13 at 18:16
  • I cant reproduce your behavior. I need more code. Like I said in the very first sentence. Show us what you up to. You are talking about styles and fallback values but we need to see code to be able to follow you. Your code is gonna show us what you doing wrong. Thought from what you just wrote to us it seems that some style is applied and you lose your value. Well take a look at dependency property value precedence http://msdn.microsoft.com/en-us/library/ms743230.aspx Might help you along. – dev hedgehog Oct 07 '13 at 19:20
  • The problem happens even without styling. Here is the [link](https://docs.google.com/file/d/0B8hssQfMfQW2OG80bjdPUXgzM2M/edit?usp=sharing) to the vs2012 project. Compile and run from IDE, enable binding information level in console. You will see the message. Thank you for help. – Plavunez Oct 08 '13 at 18:02

1 Answers1

0

Ahhhhhh now I get you. That is the most classic binding error ever. Actually its not an error its just an info. Its as harmfull as a layin youtube kitten.

Wpf handles Binding first at this point ActualHeight is zero, then wpf measures a control, then wpf sets the ActualHeight value since after measuring it knows how much space the control gets.

But you return Binding.DoNothing when ActualHeight is zero so therefore you get the info that no value has been set.

Just ignore that. No need to dispay such informations in output window anyways. Your application will perform better in debugging mode if you turn all those information displaying off.

dev hedgehog
  • 8,698
  • 3
  • 28
  • 55
  • No, the problem is not getting info off. The problem is that this info is generated when attempt is made to get fallback value on DoNothing binding. Lets assume there is a fallback value, nothing harmful in this particular example, but in other ..? – Plavunez Oct 11 '13 at 22:01
  • There is no fallback value. There is nothing. The binding give you an info that you havent set a value which is the case since you return DoNothing. Its not harmfull in any possible case. Its just a note in debugger mode that binding havent set the value. When you in release mode no binding information will be displayed hence why every application no matter if wpf or simple c# always performs better when you execute the app without attached debug/trace output. Go to settings -> debugging -> trace level or so and there you can turn on/off what shall be displayed. – dev hedgehog Oct 11 '13 at 22:42
  • You have been misled on this issue. Information messages do not come from nothing... It is coming from the part of the WPF code that accesses fallback value. As for the evidence, change the converter in my project to always return DoNothing and set fallback value to something like 8. The font in text box would be of size 8. So fallback value is in effect on DoNothing binding (and not the default or inherited font size). Now about the harmful, font size may be not very harmful, depending on the context, but something like a text in content can be :-) – Plavunez Oct 13 '13 at 00:06
  • One way of dealing with this is to submit bug report to Microsoft, but that is orthogonal to the practices collected by community. I wanted to hear what people do in similar situation (besides switching trace off :-)). Myself, I did binding in trigger that was fired after layout was arranged. – Plavunez Oct 13 '13 at 00:11
  • What you talking about is not logical to me. You return DoNothing but you had Fallback set then of course the value will be the Fallback one because setting Fallback is the same as overriding default value. That overriding happens first in WPF and then converters are being invoked. Whenever you ask a property for its value a value will be returned. It might be an actual value or default value. :) – dev hedgehog Oct 13 '13 at 12:20