I'm programming a bunch of WPF usercontrols (not CommonControls!) using an Interface for the common properties like the alignments or the Content (depending on the control; TextBox returns the Text, and Label the Content per example).
Now i get to controls like the Checkbox, which have the not so common property IsChecked.
Do i have to implement this property by the Interface or is it allowed to program it in the usercontrol itself?
I hope you're talking about binding a property to a view model or directly mentioning the property value in the xaml itself.
It actually depends upon your requirement. We normally bind a property value to a view model or code behind when that property needs to be checked by certain conditions and then to be set. If you're sure of the property's value, you can set it in xaml itself.
For example if you want to set a textbox's IsEnabled property, and you're sure that the text box is always editable. Then set it as true in xaml itself. But if you're text box need to be enabled during an event is handled, bind it to a property in view model and set it to true during the event trigger.
Okay, i have to guess it was a dumb question.
But after eight hours you don't know anymore, if you're Hillary or Donald.
The answer is: An Interface can inherit from another and implement all members from the "parent" interface.
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.
In my WPF application, my Viewmodel has a boolean property IsOwnerOf and a string property Title. If IsOwner==false, I want a TextBlock displaying the Title (because if you're not the owner, you should not be able to edit it) and if IsOwner==true, I want a TextBox displaying Title - obviously at the same place in the view.
Also I don't want to do it codebehind since I follow the MVVM pattern. Thought about Style.Triggers, but with them I can only influence attributes of an element, not the element type itself, or can I?
EDIT:
Practically the answers below regarding triggering Visibility or IsReadOnly work, but I still would like to see a conceptually better answer! What if I replace the TextBox resp. TextBlock by elements that don't have these convenient properties? There must be a better way than creating both and hiding one of them, that just doesn't sound right...
The easiest option is to always drop a TextBox and bind it's IsEnabled or IsReadOnly property to the IsOwner flag.
You can also use a DataTemplateSelector to achieve this.
You can use triggers to change the Visibility of your TextBlock and TextBox using a BooleanToVisibilityConverter
I have an ItemsControl object and am setting the DataTemplate to hold a Grid with a couple controls in it. The controls are databoud to a collection of some object MyObj, specifically a TextBlock and a ComboBox. MyObj has its own collection inside of it for a property. If that property has only 1 object in its collection, only the TextBlock is visible. But if there is more than 1 object in the collection, the TextBlock is visible and the ComboBox becomes visible once the TextBlock is clicked on.
I have the ComboBox filled up with what it needs, I just can't figure out how to specify which ComboBox needs to become visible when the TextBlock is Clicked on.
I guess my question is, how would I even go about doing this? Or, is there a better way to think about this problem?
I'm new to databinding in Silverlight and running into a bunch of issues on my own. Any help is always appreciated. Thank in advance.
One thing that you could do is add an extra property to the data item that you binding to, something like 'IsSelectionAvailable'. Make the visibility of your combobox bound to this property (via a boolean to Visibility enum Value Converter). Finally, add a click event handler for the text box that sets the IsSelectionAvailable property to true for the object it is bound to.
Hope that helps.
i am writing an application that has a viewmodel and a usercontrol that displays
data from this viewmodel. The viewmodel contains an entity "Appointment", and those
appointments have a property "UserName".
When I display the appointments, I want to use a value-converter to get a color for
the user (depending on "UserName"), but the colors are not contained in the entity "Appointment", so I wanted to create a value-converter that uses the entity "User" from the viewmodel.
What is the best way to use another entity from the viewmodel inside the converter?
Is it possible to access the viewmodel from the usercontrol? I tried to place the converter inside my viewmodel-class, but can I access this class from the usercontrol?
I figured out that the following possibilities might work:
Adjust the viewmodel so that each appointment also contains the color. But I don't want to do this because I don't want to mess with the viewmodel.
Set the converter-parameter from the class that also contains the viewmodel at startup. (Does this work?)
Use x:Reference to databind the converter parameter to the viewmodel that is unknown at compile-time.(Is this possible?)
Converter parameter is the way to go.
Why is the viewmodel unknown at compile time?
Bindings are not compile time checked anyway.
Is the UserControl.DataContext being set to an instance of Appointment, you should be able to set the parameter to {Binding UserName} or {Binding Appointment.UserName} depending on exactly what you are setting as the DataContext on the UserControl.
I would suggest that you re-examine your reluctance to modify the view model. The purpose of having a view model in the first place is so that everything that the view needs can be found in one place. Coming up with elaborate value converters to prevent modifying the view model is an approach that gets increasingly unmaintainable the more you do it.
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.