UpdateSourceTrigger and BindingExpression(Base) are missing?


  • From what I can tell the TextBox still updates its binding based on LostFocus (as it does in SL/WPF so I guess that's good that its consistent) but there doesn't seem to be a way to change/override that. There is no UpdateSourceTrigger on the Binding - not that I expected it given that SL didn't have LostFocus/PropertyChanged values in that enum anyway. However the BindingExpression(Base) classes do not seem to be available in WinRT. With the latter at least one could get the BindingExpression and call UpdateSource to force the source to be updated with the value of the target. How should one go about forcing a binding of the TextBox's Text property to push its value into the Binding?

    Tuesday, October 11, 2011 6:57 PM


All replies

  • Me too want to clarify about this UpdateSourceTrigger...

    It seems missing in WinRT. Is there any reason ?. Or It will available in the Beta ?. If no means any other work around ?.


    David C

    Wednesday, October 12, 2011 12:17 PM
  • @AndrewS Thank you for reporting this issue. We're working on mitigation.


    In the Developer Preview bits, I haven't found a way to force the source to update using binding. You can however forgo binding for now and listen for the TextChanged event and set a property manually.

    Any other scenarios you need UpdateSourceTrigger for?
    Wednesday, November 02, 2011 7:40 PM
  • @DavidC Hey sorry you're having trouble. Same as above, for now, I suggest you not use binding for this scenario and listen for TextChanged events.
    Wednesday, November 02, 2011 7:41 PM
  • Ok.


    -David C

    Thursday, November 03, 2011 4:47 AM
  • That really isn't a very good workaround. I could live with that if we could get to the BindingExpression in code and then call UpdateSource when the TextChanged was invoked. However BindingExpression(Base) doesn't exist in WinRT. We're writing 3rd party controls and we don't necessarily know the target of the binding.
    Monday, November 07, 2011 6:27 PM
  • Why is this even marked as answer? This is unacceptable. All this promoting of MVVM, and then as soon you deviate from the simplest UI expectations, you're supposed to ditch it? I don't want to wire up ten textboxes, mess with the XAML and forgo the whole MVVM thing.
    Sunday, April 29, 2012 11:53 PM
  • How about using an attached dependency property?

    Monday, April 30, 2012 9:03 AM
  • I agree to the fact that this issue/question should not be marked as solved, since it is a very poor solution in an MVVM, or any loosly coupled coding scenario for that matter. UpdateSourceTrigger with PropertyChanged came to the WP7 Mango release, so why can't you add the same thing here. Why is WinRT only Silverlight 3 XAML capable instead of Silverlight 4 or 5?

    It is also really bad that it's not even possible to implement a Behavior to solve this issue since we are missing BindingExpression and UpdateSource method, etc. In the first release of WP7 we could at least use the WP7 behavior, UpdateTextBindingOnPropertyChanged, from Prism to solve this issue, but that's not even possible here.

    Please let me know of any other possible and not so bad solution, and PLEASE fix this for the final release since the Binding functionality in WinRT feels years behind the current technologies!

    Wednesday, June 13, 2012 12:22 PM
  • Hi.

    I am starting to walk my first steps with WinRT and I was also a little bit surprised, and a bit frightened I might add, when I discovered about the inexistence of UpdateSourceTrigger property in Binding class, and the inexistance of BindingExpression thus disabling explicit bind updates (not to talk about the MultiBinding class). I suspect this has nothing to do with being preview versions of Windows 8 SDK. Instead I feel that all heavy behaviors were a filtered and purged thus leaving for the developer to implement custom scenarios. Don't forget that we can now dive into the guts of the beast using C++.

    But I bet what you need is a solution, not a dissertation.

    In fact to tackle this problem, which is keep the MVVM approach, you have two options, well two flavors of the same option.

    Create your own DependencyProperty to use as an attached behavior.

    What made sense for me was to create an attached dependency property. But by reading the new WinRT API documentation it became clear that attached dependency properties are used only with value types, but the solution I had in mind included binding to an Action<string>.

    Enough talking. Here's how I extended a TextBox to add the behavior you are talking about:

    public class ExtendedTextBox : TextBox
            public static readonly DependencyProperty CustomActionProperty =
                new PropertyMetadata(null, OnPropertyChanged));
            public Action<string> CustomAction 
                    return (Action<string>)GetValue(CustomActionProperty);
                    SetValue(CustomActionProperty, value);
            private static void OnPropertyChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
                if(e.NewValue != null)
                    (d as ExtendedTextBox).TextChanged += ExtendedTextBox_TextChanged;
                    (d as ExtendedTextBox).TextChanged -= ExtendedTextBox_TextChanged;
            async static void ExtendedTextBox_TextChanged(object sender, TextChangedEventArgs e)
                await CoreWindow.GetForCurrentThread().Dispatcher.RunAsync(CoreDispatcherPriority.Normal, () => (sender as ExtendedTextBox).CustomAction((sender as ExtendedTextBox).Text));

    I am being a little bit exausting with the use of Dispatcher since I haven't had enough time to consolidate the async programming model in WinRT.

    public Action<string> UpdateBindedViewModelProperty
                get { return new Action<string>((value) => NewLabelName = value); }

    <plmrfc:extendedtextbox customaction="{Binding UpdateBindedViewModelProperty, Mode=OneTime}" text="{Binding Path=NewLabelName, Mode=TwoWay}" width="200" x:name="Label_TextBox"></plmrfc:extendedtextbox>

    Hope it helps.

    Let me know if something's still bugging you.

    • Proposed as answer by Pedro Frederico Sunday, June 17, 2012 12:39 PM
    • Edited by Pedro Frederico Sunday, June 17, 2012 1:18 PM http://winrt8.blogspot.pt/2012/06/winrt-misses-bindingexpression-class.html
    Sunday, June 17, 2012 12:06 PM
  • That's a good alternative for this specific case. Every UI element comes with a Dispatcher property, so you don't need to go through the whole CoreWindow call flow.
    Thursday, June 21, 2012 6:10 PM
  • Well noted! ;)
    Saturday, July 21, 2012 5:54 PM
  • Very good call, I'm using this code!

    However, its very unfortunate that I have to subclass textbox and write a ton of code that I'm sure will look cryptic to me in six months, just to get around a framework restriction in a slightly more elegant way than simply handling textchanged events in code and totally breaking the MVVM model. This is definitely the better of two evils...

    Friday, August 03, 2012 2:06 PM
  • Well you should be aware that subclassing means that the implicit style that you might define needs to be your derived type - at least that's how SL/WPF have worked. So if you create a style that targets TextBox it will not affect this derived control. You will need to create a style that targets this type (although you could use the basedon to point to the textbox style). 

    To me this approach doesn't address the issue. First, you need to define and expose a delegate for every property you wish to bind to that might require this. While this might be acceptable for an application developer, for a control developer this is a real mess since this would clutter the public api with something that shouldn't even be needed. Even for an application developer I would think this would be a pain because now every time your designer is creating xaml that binds the text property they need to go to the developer to have them create a delegate that they can bind this other property to and they have to keep that in sync with the property they are binding the text property to. This is even worst if the binding of the text property was using a valueconverter because the action method would need to know to do the same logic or know what value converter was used in xaml to be able to do the same conversion.

    Also, this doesn't address the other use case about being able to get to the binding expression. That is, to be able to leave the property as updating on lost focus but conditionally being able to tell the binding infrastructure to push the value back into the source of the binding (via the UpdateSource method of the BindingExpression).

    Friday, August 03, 2012 2:22 PM
  • You can create a wrapper class so you dont have to do this each time; the source code is here: http://www.familie-smits.com/post/2012/07/29/UpdateSourceTrigger-in-WinRT.aspx and dont Bind to Text but BindableText property.
    Friday, August 03, 2012 2:37 PM
  • Yes that approach is a little more reasonable although it would be better to define this as an attached property.
    Friday, August 03, 2012 2:42 PM
  • If MS intended to make WinRT apps more responsive, by dropping this useful feature, they have presumably done the exact opposite.

    By forcing developers to come up with workarounds that tend to be less fine tuned than MS could do, might make apps and with it WinRT less appealing to consumers.

    Has MS ever thought of this? 

    The same might apply to other topics, too. Just by stripping features you don't make apps necessarily better, you just force developers to go more complicated ways or move away from WinRT completely!

    Sunday, December 23, 2012 2:04 PM
  • See my post here for a behaviour based workaround which doesn't require subclassing the TextBox:



    Sunday, December 23, 2012 9:15 PM
  • How can depending on TextChanged event help me accomplish two way binding ?

    Abhijit Ajmera

    Tuesday, February 26, 2013 8:46 AM