WPF Discussion Boards

4-Feb-12 12:40

I have three UI elements on my View that are Bound to a Property in my ViewModel:

XAML

...
xmlns:myViewModel="clr-namespace:....ThisViewModel"

<TextBlock Text="{Binding Path=LengthProperty.Name}" .../>
<TextBlock Text="{Binding Path=LengthProperty.Value}" .../>
<TextBlock Text="{Binding Path=LengthProperty.UOM}" .../>

This works as expected and shows no data when the LengthProperty is Nothing.

I want to modify this so that when the LengthProperty is Nothing, the view displays data from an alternative CavityProperty property in the ViewModel.

Can this be done in xaml? or should I code it in the ViewModel?

Any pointers are most appreciated.

I don't speak Idiot - please talk slowly and clearly

'This space for rent'

Driven to the arms of Heineken by the wife

SledgeHammer014-Feb-12 13:39

4-Feb-12 13:39

Sounds like a job for a multi value converter.

Andy_L_J4-Feb-12 15:18

4-Feb-12 15:18

I think you are right. It is the implementation I am struggling with. I assume the Converter lives with the ViewModel, however, accesing it in the view is proving probematic...

XAML

...
<TextBock.Text>
 <MultiBinding Converter="{ ??? }">
  <Binding Path="lenProp"/>
  <Binding Path="cavProp"/>
 </MultiBimding>
</TextBlock.Text>

How do I access the Converter (<MultiBinding Converter="{ ??? }"/>) ?

\_{"/)_/

I don't speak Idiot - please talk slowly and clearly

'This space for rent'

Driven to the arms of Heineken by the wife

SledgeHammer014-Feb-12 15:54

4-Feb-12 15:54

The converter doesn't live in your VM. It's a completely separate standalone class.

namespace TheSameNameSpaceAsYourVMForConvience
{
public class MyMultiValueConverter : IMultiValueConverter
{
}
}

then in your XAML, in your resources section (assuming local is pointing to your namespace):

<Window.Resources>
<local:MyMultiValueConverter x:Key="MyMultiValueConverter" />
</Window.Resources>

to access it:

<MultiBinding Converter="{StaticResource MyMultiValueConverter}">
</MultiBinding>

The logic in your convert function is going to be something like:

if ((string)values[0] != null && (string)values[0] != "")
return values[0];

return values[1];

Andy_L_J4-Feb-12 17:42

4-Feb-12 17:42

I have solved this (temporarily) in the ViewModel by creating a Public MultiProperty() As ProdPropertyItem which calls a Function ValueConverter() As ProdPropertyItem that resolves the correct property.

I call the function in the Property Setter when a new Parent Item is seleted and the correct values are displayed in the UI Thumbs Up | :thumbsup:

. However, this enables OneWay binding only.

I will re-investigate the MulitiBinding Converter stuff when I get more time.

(Infact I have tried pretty similar code to what you have posted, although I am not yet seeing the fields of the converted property)

I don't speak Idiot - please talk slowly and clearly

'This space for rent'

Driven to the arms of Heineken by the wife

Mycroft Holmes4-Feb-12 17:00

4-Feb-12 17:00

Alternatively set up 2 sections, 1 binding to the Length and the other binding to the Cavity, another 2 properties determining the visibility of the 2 sections based on the content.

Not sure if this is the most appropriate solution but it does seem logical and possibly simpler.

Never underestimate the power of human stupidity
RAH

Andy_L_J4-Feb-12 17:48

4-Feb-12 17:48

Thanks Mycroft, this is what I have basically done by exposing a Single "SharedProperty" Item and wiring up the visibility in the ViewModel.

I still feel that I should be able to detrmine the appropriate Object in xaml and then display the(3) public properties in the UI without creating extra Public Properties in the ViewModel.

(Disclaimer: I am a novice to this and have only just recently had my MVVM + WPF LightBulb Moment[^] so I may have this a bit screwed!) Big Grin | :-D

I don't speak Idiot - please talk slowly and clearly

'This space for rent'

Driven to the arms of Heineken by the wife

Mycroft Holmes4-Feb-12 21:04

4-Feb-12 21:04

Andy_L_J wrote:
I still feel that I should be able to detrmine the appropriate Object in xaml and then display the(3) public properties in the UI

I wonder why? While the converter may be the technically correct method I feel the VM should do whatever it needs to service the views requirements. I often create a bunch bool(s) in the VM to manage the state of the view based on the data content.

I also consider the use of a converter to be more obscure from a support point of view which for me is a large consideration.

Never underestimate the power of human stupidity
RAH

Andy_L_J4-Feb-12 22:05

4-Feb-12 22:05

Mycroft Holmes wrote:
I still feel that I should ...

Thats it, it's just a "feeling", due no doubt to my inexperience with this pattern. I have been coding (3/4 Tier) Windows Apps using CSLA and have found the transition a little difficult at first. I am also digging into Entity Framework and Linq to Entities so am having a great time of it.

From my point of view, it was very easy to accomplish my goal in the VM. And as for two-way binding, since I dont intend updating the Model from this view there is no issue. There will be a separate view to performm the New/Edit operations.

I don't speak Idiot - please talk slowly and clearly

'This space for rent'

Driven to the arms of Heineken by the wife

Mycroft Holmes5-Feb-12 0:58

5-Feb-12 0:58

I have to admit, I cheat with the multiple view/VM structure. I often service 2 different views from the same VM. The list is fairly simple, 1 observable collection with a selected item. The dialog (Add/Edit) is also serviced by the same view using the IEditable from the underlying model to determine the state. A bunch of standard CRUD methods and the VM is done for simple operations. Takes about 15 minutes for a table/model/WCF DAL/VM/2 Views for a simple operation.

Never underestimate the power of human stupidity
RAH

SledgeHammer015-Feb-12 7:53

5-Feb-12 7:53

Mycroft Holmes wrote:
I often create a bunch bool(s) in the VM to manage the state of the view based
on the data content.

Which is often extremely silly, unnecessary, unmaintainable and not the right way to go.

1) If you write a generic converter, you can often re-use it, not only for multiple properties, but multiple views.

By generic converter, no, I don't mean one that converts empty strings to "(Empty)" and another one that converts falses to "Off" for example. I mean, one that say could convert any object & value to any other object & value.

A few EXCELLENT examples of true GENERIC converters: a map converter and a math converter

Too often I see BoolToVisibilityConverter and InverseBoolToVisibilityConverter, etc. when you could have done both and then some with the generic MapConverter.

2) Other then the generic converters, the other option is of course triggers. I'm betting I could re-write 90% of your bool view state properties as one line triggers.

Mycroft Holmes5-Feb-12 11:01

5-Feb-12 11:01

SledgeHammer01 wrote:
I'm betting I could re-write 90% of your bool view state properties as one line triggers.

I will decline that bet thanks.

How would you handle setting the visibility based on the value of a field?

Never underestimate the power of human stupidity
RAH

SledgeHammer015-Feb-12 11:49

5-Feb-12 11:49

Here is part of one I wrote for a custom control. It's not a one liner obviously because it's more complicated, but its setting the visibility based on *4* conditions Smile | :)

XML

<DataTemplate.Triggers>
    <MultiDataTrigger>
        <MultiDataTrigger.Conditions>
            <Condition Value="1">
                <Condition.Binding>
                    <MultiBinding Converter="{StaticResource HeaderArrowConverter}">
                        <Binding RelativeSource="{RelativeSource Mode=TemplatedParent}" />
                        <Binding Path="View.AllowsSorting" RelativeSource="{RelativeSource Mode=FindAncestor, AncestorType=ctrls:ListViewEx}" />
                        <Binding Path="View.SortColumn" RelativeSource="{RelativeSource Mode=FindAncestor, AncestorType=ctrls:ListViewEx}" />
                        <Binding Path="View.SortDirection" RelativeSource="{RelativeSource Mode=FindAncestor, AncestorType=ctrls:ListViewEx}" />
                    </MultiBinding>
                </Condition.Binding>
            </Condition>
        </MultiDataTrigger.Conditions>
        <MultiDataTrigger.Setters>
            <Setter TargetName="arrow" Property="Data" Value="{StaticResource HeaderArrowUp}" />
            <Setter TargetName="arrow" Property="Visibility" Value="Visible" />
        </MultiDataTrigger.Setters>
    </MultiDataTrigger>

When the value is returned as 1 from the converter, that trigger executes. I haven't had a case where I have to handle a range of values in one trigger, but I have seen some solutions online for that. Instead of having just "1", you can have something like "> 1 && < 5" or however they specify it.

A simple "one liner":

XML

<Trigger Property="SomeProp" Value="15">
    <Setter Property="Visibility" Value="Collapsed" />
</Trigger>

modified 5-Feb-12 18:21pm.

Mycroft Holmes5-Feb-12 12:15

5-Feb-12 12:15

Interesting, this is not an area I have spent any time exploring (obviously). While I see this as 1 possible (and in this case generic) solution, it is not a simple or straight forward solution. I put this in the bucket of complex but generic code and it *may* be used again so it would be the preferred solution.

I had in mind where the visible condition is based on the content of 1 or more fields, not bools but string or numeric. Something that is really specific to only that one view, I would still use code in the VM to evaluate the current record!

Never underestimate the power of human stupidity
RAH

SledgeHammer015-Feb-12 12:26

5-Feb-12 12:26

Mycroft Holmes wrote:
I had in mind where the visible condition is based on the content of 1 or more
fields, not bools but string or numeric. Something that is really specific to
only that one view, I would still use code in the VM to evaluate the current
record!

That is what I showed in my more complex example. The multi-converter takes in 4 values and returns a decision based on those 4 values. I only showed you a small portion of that trigger, but there are actually 5 cases "1", "2", "3", "4", "5".

The problem with your solution is that you may leave holes where you update one of the values used in the calculation but forget the OnPropertyChanged("VisibilityForState1"); call.

I have done it your way in the past, but found that I didn't like having to put OnPropertyChanged() calls for 4 or 5 properties all over the place.

Also, I kind of believe that the VM should strictly be for communication between the V and M. Adding a bunch of properties to support the view couples them more closely then they should be.

Mycroft Holmes5-Feb-12 13:15

5-Feb-12 13:15

SledgeHammer01 wrote:
The problem with your solution is that you may leave holes where you update one of the values used in the calculation but forget the OnPropertyChanged("VisibilityForState1"); call.

Yeah that is one of the main drawbacks. I often throw all the conditional tests into 1 method and call that from multiple events. Which is basically what you are doing in xaml duh!

I can see some research into triggers are going to be needed!

Never underestimate the power of human stupidity
RAH

SledgeHammer015-Feb-12 14:14

5-Feb-12 14:14

Mycroft Holmes wrote:
Yeah that is one of the main drawbacks. I often throw all the conditional tests
into 1 method and call that from multiple events. Which is basically what you
are doing in xaml duh!

I can see some research into triggers are
going to be needed!

One other thought I had about your approach while I was watching TV was that unless you **really** know the VM and its view bindings and how everything works together, you run the real risk of un-necessary / unintentional (and potentially expensive) screen updates.

By "throwing multiple updates in to one function" as you said, you could unintentionally trigger updates for say a few hundred properties when you just updated one. Maybe not on purpose Smile | :)

, but by accident.

By doing this via triggers and self enforcing the rule that only the setter for PropertyA is allowed to put up a OnPropertyChanged("PropertyA") notification (and nothing else), you really mitigate this risk and optimize screen updates. All your setters should of course have "if (_theProp != value) { }" checks.

Now, with my trigger example where I bind to 4 properties in a multivalue converter, and I only change one of them, yeah, its going to call the converter function again, but the other 3 values are already cached by WPF. Also, there is very little overhead as the converter instance is cached as well, so you aren't recreating it.

Heck, you don't even need to do it that way. If your conditions are "basic", you can have a multiple condition trigger without the use of a converter at all.

The reason I had to use a converter there was because the logic that returned 1,2,3,4 or 5 was more complex then XAML allowed.

Mycroft Holmes5-Feb-12 15:15

5-Feb-12 15:15

SledgeHammer01 wrote:
By "throwing multiple updates in to one function" as you said,

No no no no -- multiple criteria for 1 update. Although the possibility does exists for your scenario and yeah it is a very valid argument for the trigger requirement.

Never underestimate the power of human stupidity
RAH

Mycroft Holmes5-Feb-12 15:16