Re: Groupbox visibility problem in WPF after debugging and changing the combobox value - WPF Discussion Boards

Re: Groupbox visibility problem in WPF after debugging and changing the combobox value

9-Aug-12 0:31

Same sample but with three optins in the combo box working on visibility of two group boxes.

XML

<StackPanel>
    <ComboBox Name="Options">
        <sys:String>One</sys:String>
        <sys:String>Two</sys:String>
        <sys:String>Three</sys:String>
    </ComboBox>
    <GroupBox Header="OneOrThree">
        <GroupBox.Style>
            <Style TargetType="GroupBox">
                <Setter Property="Visibility" Value="Collapsed"/>
                <Style.Triggers>
                    <DataTrigger Binding="{Binding ElementName=Options, Path=SelectedItem}" Value="One">
                        <Setter Property="Visibility" Value="Visible"/>
                    </DataTrigger>
                    <DataTrigger Binding="{Binding ElementName=Options, Path=SelectedItem}" Value="Three">
                        <Setter Property="Visibility" Value="Visible"/>
                    </DataTrigger>
                </Style.Triggers>
            </Style>
        </GroupBox.Style>
    </GroupBox>
    <GroupBox Header="Two">
        <GroupBox.Style>
            <Style TargetType="GroupBox">
                <Setter Property="Visibility" Value="Collapsed"/>
                <Style.Triggers>
                    <DataTrigger Binding="{Binding ElementName=Options, Path=SelectedItem}" Value="Two">
                        <Setter Property="Visibility" Value="Visible"/>
                    </DataTrigger>
                </Style.Triggers>
            </Style>
        </GroupBox.Style>
    </GroupBox>
</StackPanel>

karthik bandaru9-Aug-12 0:42

karthik bandaru

9-Aug-12 0:42

ok Thank you but my form contains so many groupboxes which will be changed as per selecting the combo items.. I appreciate your help. Smile | :)

Any other method of writing it in codebehind by using a switch case will be helpful.

Re: Groupbox visibility problem in WPF after debugging and changing the combobox value

Ed Hill _5_9-Aug-12 0:56

Re: Groupbox visibility problem in WPF after debugging and changing the combobox value

9-Aug-12 0:56

I have provided you with a sample using the code behind, but i would say that it is worth getting used to all the things that you can do with WPF in the xaml files. As with any programming there are so many ways to do things, the styles i was suggesting can be created as resources and be reused easily by the group boxes. If you are using the MVVM approach what you may be looking to do is use templates to get your UI to change depending on Properties in the ViewModel. Just as a quick untested example if you are worried about having too much xmal, this is just a different appraoch.

It is worth noting that the resources can be placed in different places, and the are in scope in any elements below where they are created, also they can be kept out of the way in resource dictionarys. Hopefully one of these solutions will work for you even if it is the code behind one.

XML

<StackPanel>
    <StackPanel.Resources>
        <Style TargetType="GroupBox" x:Key="OneAndThree">
            <Setter Property="Visibility" Value="Collapsed"/>
            <Style.Triggers>
                <DataTrigger Binding="{Binding ElementName=Options, Path=SelectedItem}" Value="One">
                    <Setter Property="Visibility" Value="Visible"/>
                </DataTrigger>
                <DataTrigger Binding="{Binding ElementName=Options, Path=SelectedItem}" Value="Three">
                    <Setter Property="Visibility" Value="Visible"/>
                </DataTrigger>
            </Style.Triggers>
        </Style>
        <Style TargetType="GroupBox" x:Key="Two">
            <Setter Property="Visibility" Value="Collapsed"/>
            <Style.Triggers>
                <DataTrigger Binding="{Binding ElementName=Options, Path=SelectedItem}" Value="Two">
                    <Setter Property="Visibility" Value="Visible"/>
                </DataTrigger>
            </Style.Triggers>
        </Style>
    </StackPanel.Resources>
    <ComboBox Name="Options">
        <sys:String>One</sys:String>
        <sys:String>Two</sys:String>
        <sys:String>Three</sys:String>
    </ComboBox>
    <GroupBox Name="group1" Header="OneOrThree" Style="{StaticResource OneAndThree}">
    </GroupBox>
    <GroupBox Name="group2" Header="Two" Style="{StaticResource Two}">
        <!--<GroupBox.Style>
            
        </GroupBox.Style>-->
    </GroupBox>
</StackPanel>

Ed Hill _5_9-Aug-12 0:47

Re: Groupbox visibility problem in WPF after debugging and changing the combobox value

9-Aug-12 0:47

if you are set on doing this in the code behind then i think i will need a better sample or your code to help you. The following is working for me:

XML

<StackPanel>
    <ComboBox Name="Options" SelectionChanged="SelectionChanged">
        <sys:String>One</sys:String>
        <sys:String>Two</sys:String>
        <sys:String>Three</sys:String>
    </ComboBox>
    <GroupBox Name="group1" Header="OneOrThree">
        
    </GroupBox>
    <GroupBox Name="group2" Header="Two">

    </GroupBox>
</StackPanel>

private void SelectionChanged(object sender, SelectionChangedEventArgs e)
{
    var selected = (sender as ComboBox).SelectedItem as String;
    switch (selected)
    {
        case "One":
            group1.Visibility = Visibility.Visible;
            group2.Visibility = Visibility.Collapsed;
            break;
        case "Two":
            group1.Visibility = Visibility.Collapsed;
            group2.Visibility = Visibility.Visible;
            break;
        case "Three":
            group1.Visibility = Visibility.Visible;
            group2.Visibility = Visibility.Collapsed;
            break;
        default:
            group1.Visibility = Visibility.Collapsed;
            group2.Visibility = Visibility.Collapsed;
            break;
    }
}

It would be worth throwing some checks in on the (sender as ComboBox) etc incase you call the event from the wrong place but i'll leave that to you to sort out

karthik bandaru9-Aug-12 0:50

karthik bandaru

9-Aug-12 0:50

thank u .. i will try and reply u

Re: Groupbox visibility problem in WPF after debugging and changing the combobox value

karthik bandaru9-Aug-12 2:10

karthik bandaru

9-Aug-12 2:10

should I set all the groupboxes visible or hidden in pageload ?

I have taken grid inside the groupboxes and arranged my controls like textboxes..
If I make groupboxes visible in pageload then while debugging it is showing all the controls in Groupboxes but combo selection change event not working.

Re: Groupbox visibility problem in WPF after debugging and changing the combobox value

Ed Hill _5_9-Aug-12 2:24

Regarding MVVM framework for WPF

9-Aug-12 2:24

have you put a break point in to check that the SelectionChanged Event is being triggered and passed through to the event handler?

If you don't set the vivibility explicitly in the PageLoad is the combo box working as expected?

I'm not able to reproduce your problem here at all from the information you have provided, so include the WPF where you decalre your combo box, page load event and at least one group box. also include the code for your selection chanage event handler and page load event handler.

Or send me your project via email(my profile > right click homepage >copy link location) email address is there for a short while.

modified 9-Aug-12 8:32am.

Member 92251325-Aug-12 3:55

Member 9225132

5-Aug-12 3:55

Hi everyone,
This is Sunil here. I am trying to find a job in WPF field having 1 Years of experience. But, i have some basic knowledge of WPF, actually my field was in Win-forms. But, nowadays WPF is future oriented technology, so i want to build carrier in WPF. I have some basic knowledge in Data-binding, animation, styles and templates etc. I have to know which framework is more required by software companies in MVVM among Prism, MVVM Light, Cliburn. I have basic practical knowledge in MVVM light framework. It's very simple to implement as compare to Prism. So, friends, Please guide me which framework should i read regarding Job in a S/W company? Any other link for that?

Thanks and Regards:
Sunil Paul,
9718629366

Re: Regarding MVVM framework for WPF

Richard MacCutchan5-Aug-12 6:55

Richard MacCutchan

5-Aug-12 6:55

I already answered this question here[^]. Please post your question in one forum only.

One of these days I'm going to think of a really clever signature.

WPF Update UI When Collection Changes

Kevin Marois1-Aug-12 11:05

1-Aug-12 11:05

When I change an item in an ObservableCollection, how do I update the UI?

I have an ObservableCollection of AddressEntity.

When I change an street on an item in the collection, the UI doesn't reflect it.

If it's not broken, fix it until it is

Pete O'Hanlon1-Aug-12 11:44

Pete O'Hanlon

1-Aug-12 11:44

The ObservableCollection effectively just updates the UI when items are added, removed, moved, etc. If you want to update the UI based on a change to the property then you have to raise the change notification on that property (via INotifyPropertyChanged).

*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington

"Mind bleach! Send me mind bleach!" - Nagy Vilmos

CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier

Kevin Marois1-Aug-12 11:52

1-Aug-12 11:52

You mean implement INotifyPropertyChanged in the AdressEntity?

If it's not broken, fix it until it is

Pete O'Hanlon1-Aug-12 12:10

Pete O'Hanlon

1-Aug-12 12:10

Yes. That's how WPF receives information that only a particular property has changed (don't forget that the BindingMode has to be considered here as well). The BindingMode tells WPF which direction change notification goes.

*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington

"Mind bleach! Send me mind bleach!" - Nagy Vilmos

CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier

Kevin Marois1-Aug-12 12:23

1-Aug-12 12:23

Thats where I thought you were going.

Then I thought, right now, my entities are simply made up of auto-implemented properties. This means I have to implement each property. That's a hell of alot of code to add to each entity, especially considering my entites are going to be used in an MVC3 app as well as my WPF app. That would mean putting WPF-specific code in classes use for non-WPF platforms.

This doesn't feel right.

If it's not broken, fix it until it is

Pete O'Hanlon1-Aug-12 12:45

Pete O'Hanlon

1-Aug-12 12:45

How have you autogenned those properties? If it's Entity Framework for instance, it can auto gen the prop change code for you.

*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington

"Mind bleach! Send me mind bleach!" - Nagy Vilmos

CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier

Kevin Marois1-Aug-12 12:51

1-Aug-12 12:51

No, simply

public string Caption {get; set; }

How their generated is irellevant here. The entities are in a seperate Entities project used by 2 diferent UI projects - WPF and Web.

So now we're talking about going from

public class AddressEntity : _EntityBase
{
    public string Caption { get; set; }
    public string Street1 { get; set; }
    public string Street2 { get; set; }
    public string City { get; set; }
    public string State { get; set; }
    public string ZipCode { get; set; }
}

private string _Caption = string.Empty;
public string Caption 
{
    get { return _Caption; }
    set
    {
        if (_Caption != value)
        {
            _Caption = value;
            RaisePropertyChanged("Caption");
        }
    }
}

.
.
.
.
}

That's a tremendous amount of code in many entities just to support WPF.

One possibility is in the WPF UI simple reload the list from data.

If it's not broken, fix it until it is

Mycroft Holmes1-Aug-12 13:10

Mycroft Holmes

1-Aug-12 13:10

Kevin Marois wrote:
How their generated is irellevant here

Even I beg to differ here, a good code generator is priceless. I believe EF 4 does this but I wrote my own many years ago and would not work without it!

You basic issue still exists and is one I am contemplating, UI code in your entity (model in my case) classes that is used by a non UI consumer. This is precisely what we do, the WCF and the Silverlight UI reference the same model which has fully implemented properties.

Never underestimate the power of human stupidity
RAH

Kevin Marois1-Aug-12 13:27

1-Aug-12 13:27

My point was, whether generated by a tool, or typed in my me, is irellevant.

If it's not broken, fix it until it is

Kevin Marois6-Aug-12 7:25

6-Aug-12 7:25

Speaking of EF - I spent some time over the weekend looking at EF, as I hadn't used it before. Seems simple, but the Entities seem heavy compared to the POCO's I'm currently using.

Also, assuming the DAL is going to be hit via a WCF service, would you use EF entities to transports the data? This really seeme smore suited to POCO's.

If it's not broken, fix it until it is

Mycroft Holmes6-Aug-12 12:38

Mycroft Holmes

6-Aug-12 12:38

I haven't used EF, or even looked at it. I went on the feedback over the last few years that it was buggy and could be difficult to use. With the release of v4 apparently they have improved to a usable product, however I am reluctant to throw away my current framework and I have no intention of re factoring 13 projects currently in production or UAT!

Never underestimate the power of human stupidity
RAH

SledgeHammer011-Aug-12 13:15

SledgeHammer01

1-Aug-12 13:15

Kevin Marois wrote:
That's a tremendous amount of code in many entities just to support WPF.

One possibility is in the WPF UI simple reload the list from data.

As Pete mentioned, your AddressEntity needs to implement INotifyPropertyChanged. Well, actually, I hope you have all that encapsulated in a base class and you just derive everything from ObservableObject or whatever Smile | :)

.

In regards to your idea of reloading the list, that'll only work on the surface level, but it'll break a LOT of things. Lets say you have a collection tied to a ListBox or whatever and the user has Item5 selected and clicks the edit button and changes the name to Item5a. The way you have it now, the ListBox will continue to display Item5 because INotifyPropertyChanged was not implemented. So you'd try to refresh the entire list, now you'll run into an issue where Item5a has lost its selection, the h & v scroll positions will be lost as well, etc. Not a good UI when that happens Smile | :)

.

Anyways... if you aren't using EF, how many properties are we talking about? 5, 10, 50, 100?

I think if it was 5 to 10, I would just hand job it with c&p... but if it started to get closer to 50 or 100 or more, I would probably just write a quick & dirty C# app that loaded up your .cs file and simply parsed each line. The return type would be the 2nd value and the property name would be the 3rd value. Your app can then auto-gen all the WPF code. Probably a 10 to 20 minute job tops to whip out a C# app that does that.

Nothing wrong with a non WPF app using the code since the PropertyChanged event will be null, your handler will just return.

Kevin Marois1-Aug-12 13:32

1-Aug-12 13:32

I know all this, and I considered adding in the RaisePropertyChanged. Is just seems out of place for entities. In my mind, entities simply transport data to & fro - not worry about updating the UI.

I have also been considering creating a property generator tool. Pop it off the menu, fill it out, and it adds a new property to your class. Would have options including RaisePropertyChanged etc.

If it's not broken, fix it until it is

Mycroft Holmes1-Aug-12 14:17

Mycroft Holmes

1-Aug-12 14:17

Kevin Marois wrote:
In my mind, entities simply transport data to & fro - not worry about updating the UI

This is the issue I am currently debating, the alternative seems to be to have yet another set of entities that extend the POCO transport objects with the UI functionality and additional properties.

You then need to translate between the 2 object types etc. etc. One of our senior devs has experience with EF4 and is recommending that and I know some here approve of it!

Never underestimate the power of human stupidity
RAH