ansaurus

Question

Answer 1

A:

Is your object a DependencyObject? Is the property you're binding to a DependencyProperty? If they are, you don't need to specify the trigger. If they aren't, I'd suggest making them so. Its the easiest way to create a reliably bindable object.

I think the delays are related to your use of the UpdateSourceTrigger. I don't think it does what you think it does, which is why its not behaving as you expect.

Drop the UST, and if that doesn't work refactor your binding object to be a DO and PropertyOne to be a DP. Trust me, once you get through the pains of learning DependencyObjects, its well worth it.

Will 2009-03-26 11:39:10

Care to explain why?

Will 2009-03-26 11:44:44

Why would the delays be related to the UpdateSourceTrigger. What does he think it does? What do you think it does? You can easily bind a textbox to a non dependency property and the XAML above should work. Also, what if his class lives in a separate library that he can't modify?

siz 2009-03-26 13:43:38

I can't answer what he thinks or what he's doing. I'm trying to go on what information he gave. Apparently he's experiencing multithreading issues. He didn't mention he was multithreading. Also, what if every what if ever?

Will 2009-03-26 14:01:27

My problems with this:1. You don't explain what UST does, how he might be using it incorrectly. 2. Doesn't matter whether it is a DO or not. The XAML above should work, it doesn't.3. If he drops the UST, it definitely won't work.You're right, my what if was contrived.

siz 2009-03-26 15:45:43

1. I'm going on a single line of xaml, trying not to make too many assumptions about his code 2. OMG his UST only works if he's implementing INotifyPropertyChanged; we don't KNOW he is 3. Bullcrap. It only works with INPC; doesnt work with pocos and isn't needed with DPs

Will 2009-03-26 16:55:44

You are wrong Will. WPF bindings will bind to any CLR property. Depending on the BindingMode different things are required of that property. (ie, TwoWay requires a getter/setter on the property). TextBox binding to a property works just fine as long as there is a setter defined. Try it out in VS.

siz 2009-03-26 17:53:46

Take a look at this: http://rafb.net/p/eumGr283.html. The value gets propagated to the Data object just fine without INPC.

siz 2009-03-26 17:59:26

You misread me. I said that the UST only works with the INPC; the PropertyChanged update source trigger eminates from the INPC. Bindings ignore the UST if your objects don't implement the interface.

Will 2009-03-27 10:16:18

What you are saying is true for the Destination property/object. UST determines what action causes an update on the Source property from the Destination object. If it is PropertyChanged, the destination has to be DO or INPC, you are correct. But this isn't the case in the original question.

siz 2009-03-27 15:09:30

True. I thought it was useless, and that maybe a side effect was causing his odd behavior. Remote chance, yeah, but I figured it wouldn't do any harm. DO's are pretty much bulletproof when it comes to binding, so that was my second recom'd. Not the solution, but not worthy of -2 imho.

Will 2009-03-29 17:00:43

Answer 2

+1 A:

If I change the values in a few textboxes then quickly try to access the properties to which they map

I can interpret this statement in two ways:

You're trying to access the values on a background thread. In that case, you may be accessing the properties before the UI thread has had a chance to do its thing.
You're using a separate message on the UI thread to check the values. Bindings are updated at a priority lower than Send and Normal. So if your message is priority Send or Normal it will be processed before any pending binding updates.

If this doesn't answer your question, please clarify what you mean by "quickly trying to access the properties".

HTH, Kent

Kent Boogaart 2009-03-26 11:46:03

That's what I was thinking. With the object being the DataContext, I'm accessing it from a BackgroundWorker, which may be why it doesn't get chance to update. I'll try calling UpdateSource on the bindings before starting the BackgroundWorker.

Echilon 2009-03-26 12:06:24

Answer 3

A:

The basic rule of WPF Databinding is simple:

The target property must be a dependency property, and you're already correct, it's bound to Text property of TextBox.
The source property can be a CLR object (other than any derived WPF's DependencyObject), but the object must employ or implement its own INotifyPropertyChanged.

Have you you already implemented INotifyPropertyChanged on your object?

eriawan 2009-03-26 11:52:45

All of the object's properties fire NotifyPropertyChanged events. I think Kent Boogart might have nailed it with accessing from another thread before the UI has updated the object's properties.

Echilon 2009-03-26 12:07:31

Yes, but are sure your objects have implemented the INotifyPropertyChanged interface? Kent Boogart answer touches different view and his answer is different than mine.

eriawan 2009-03-26 12:40:37

Just a comment on point two: the INotifyPropertyChanged implementation matters _only_ if Echilon is doing clrObject.PropertyOne = "some value" and wants the TextBox to change its text; the point is valid only if you are doing two way binding.

siz 2009-03-26 16:05:11

ansaurus

tags:

views:

answers:

WPF: Bindings - Object not updated

related questions