I've been using the .Net binding in Win Forms. I would like the bound property to be updated as soon as the user alters the value in the corresponding control. To achieve this I have set the Data Source Update Mode to OnPropertyChanged. Unfortunately, when i navigate away from the page the Focus Changed event causes Validation to occur again, which also causes the value to be set. Is there anyway to prevent this or work around it (other than setting the update mode to never) and pushing update manually?
Seems i just needed to set CausesValidation to false on all the related controls
Related
I have a view model property that is set to runtime objects. I want to trigger an animation whenever this property changes, so I was planning to use DataTrigger. However, DataTrigger obviously has the requirement for a Value property--one that I don't know at design-time.
Is there a built in way to trigger an animation whenever a value changes, regardless of what it changes into?
I saw this question but I was wondering if there was anyway to do it purely in XAML. Otherwise I figure I could probably fire an event from my View Model whenever the property changes and listen to that.
One method would be to create a User Control with a dependency property and then bind both of your other properties to that i.e. one at compile time and the other at runtime. Alternatively you could use an Attached Behaviour to do the same thing.
Can add a boolean property and trigger the animation based on the bool property. Whenever the original property changes, set and reset the boolean property so that it triggers the animation and also goes back to default value for next notification.
I have a DataGridView with a binding source to an interface that has a bool. When I click the checkbox that is created in the grid, nothing happens. The value is not set and the box does not get checked.
However, and this gets very case specific, if I set a binding source to a completely different control in the same view then the checkbox in the first control is possible to click. The downside to this is that every DataGridView when loaded has a large portion of it that is completely black.
sorry I have no point to make this as a comment.
anyway did you check that the column of the DataGridView is set as readOnly = false, or enable = true.
check it also in run time, make a break point before and after doing the binding and see how your grid is set up.
Also if you can give some code maybe will see some other issue that can make this happen.
good luck
So I was asked to fix an issue with an old windows form utility that has been around a little while (least before any of my coworkers showed up). The form has a numericUpDown control that is databound. The issue was, when you clicked the up or down arrow the values would change and save OK however, if you just typed in a number and clicked save it wouldn't save. It was like the databinding never saw the change, so coming from a WPF background I guessed that changing the following
TaskDaysToComplete.DataBindings.Add("Value", taskTemplate, "DaysToComplete");
To this
TaskDaysToComplete.DataBindings.Add("Value", taskTemplate, "DaysToComplete", false, DataSourceUpdateMode.OnPropertyChanged);
would solve my problem and it did. You can now either type in a number or use the up/down arrows on the control to set the "Value" property.
My question is this, what was happening in the first place? I am guessing the default DataSourceUpdateMode was OnValidation but when does this happen and why was it OK for when using the up/down arrows but never seemed to happen when typing things in.
Thanks!
numericUD validation
validation is done on losing focus, so when you press the up/down key the textbox loses focus - triggering the validation routine.
when editing text you can make the control lose focus by clicking another control, this will cause it to validate.
the reason that the default is set to onValidate is that on value changed will cause it to validate on each character typed, which can be problematic both for performance and for correct validation.
Does it make sense that if the Text on a TextBox is databound to a property using the twoway mode and I set the Text to something, it should update the property? My property gets updated when I type inside the control, but not when I set the value in code.
I would say it makes no sense to modify a bound Text property directly. Your code should be setting the other end of the binding and allowing the binding to update the control.
If the bound object is updated when the Text property is set then special case code would be needed to detect when such an assignent is the result of the bound object changing for other reasons. Otherwise you would end up with an infinite loop.
You shouldn't set the .Text value of the textbox... set the value of the property it's binding to. :)
I'd encourage you to read more about the Model-View-ViewModel method for designing your views. It keeps a clear separation of concerns when doing this kind of work. The reason you are seeing this "bug" regarding focus causing the binding to refresh is because most of the time this kind of thing is not appropriate.
Here's a pretty good video introduction to MVVM: MVVM on Channel 9
This is because it only commits the data when the textbox loses focus. Here is a question that is somewhat related that eludes to this.
I have a disabled TextBox that I am editing the value of on the client side with JavaScript. When I try to retrieve the value on the server side it does not reflect the change made on the client side. If I set the TextBox's enabled attribute to true I can retrieve the value, but the user is able to put focus and edit the TextBox.
Is there a sane way to keep the user from giving focus and editing to the TextBox?
Use the textbox's ReadOnly property.
Edit: Based on OP's comment, this will probably not do the trick then.
Edit 2: From DotNetSlackers:
So what's the difference between these
two properties and why do both exist?
There are two differences between
these two properties, a trivial
difference and a subtle, profound one:
The two properties emit different markup. When you set Enabled
to False, the TextBox injects the
attribute disabled="disabled" intoits
rendered HTML. When you set the
ReadOnly property to True, the
attribute readonly="readonly" is
injected.
According to the W3C spec on HTML forms, disabled controls areNOT
"successful," while read-only controls
MAY BE "successful." A "successful"
control is one whose name/value pair
is sent back to the browser through
the POST headers or querystring.
Therefore, disabled controls are NOT
sent back to the ASP.NET page, while
read-only controls may be, depending
on the User Agent. (In my tests,both
IE 6and FireFox 1.5 send along the
read-only TextBox input.)
......
If you encountered this problem in
ASP.NET version 1.x you might have
found the TextBox's ReadOnly property
and used that instead of setting
Enabled to False. You could still have
a page's ViewState disabled and set a
read-only TextBox Web control's Text
property programmatically because the
TextBox value is sent back through the
form submission for read-only
controls. However, in ASP.NET version
2.0, things change just a bit, as noted by Rick Strahlin his blog entry
ASP.NET 2.0 ReadOnly behavior change
when EnableViewState is false. With
2.0, the TextBox control'sReadOnly property's behavior has changed
slightly. From the technical docs:
The Text value of a TextBox control with the ReadOnly property set to true is sent to the server when a postback occurs, but the server does no processing for a read-only text box. This prevents a malicious user from changing a Text value that is read-only. The value of the Text property is preserved in the view state between postbacks unless modified by server-side code.
What happens is that the client sends
along the value of the read-only
TextBox through the form values, but
the ASP.NET 2.0 engine does not take
that value and assign it to the Text
property of the TextBox on postback to
help protect against a malicious user
changing the read-only TextBox value
themselves. But this brings us back to
our earlier problem - if the value
isn't specified in the postback (or is
ignored, in this case) and ViewState
is disabled, the value will be lost.
Eep.
Rick'sworkaround was to just manually
read the value from the request
headers (this .TextBox1.Text =
Request[this.TextBox1.UniqueID];),
which poses a security risk and
introduces the problem that 2.0
addresses. The optimal approach is to
requery the value from the database
(or wherever you initially got the
programmatically-set value for the
read-only TextBox).
The moral of this blog post is that if
you have read-only data you can use
either disabled or read-only form
fields, it really doesn't matter
whether or not you receive back the
value of the form field in the form's
submissions. It shouldn't matter
because you shouldn't be
trusting/using that data to begin
with! If you have read-only data,
don't re-read it from a data stream
that the end user can tinker with!
Source
Browsers don't post values back in disabled input controls, as you've discovered. Probably the easiest way to work around this is to hook onto form submission, and re-enable the input as the form is being submitted; the user won't have a chance to edit the value, and it should get posted with the rest of the request.
An alternative might be to inject a hidden element into the form; this could either be maintained by your script, mirroring the displayed value, or added at the end, in a similar fashion to the above.