Reusable Lookup Control [modified]
-
I'm trying to create a lookup that can be used in many places within my application, it is to display a list of activities. It is to be used in several places, each with their own DataContext, as the application dosn't have one static context used by all forms. All instances of the context are from the same Entity Model. The first issue i had was on one form i have a databound list view containing usercontrols as the item template, this user control contained the lookup in question. The lookup needs to share the same context as the form. This was a bit of an issue as i could not find an simple way of doing this, so i created an event in the lookup that requests a context, this is handled by the form. The lookup contains a Dependancy Property called Value, of the type Activity, the user control binds its Activity to the Value, but also shows some other information about the activity, this is where my issue is, this fails to update when the activity is changed. Ideally i would like to avoid any process that manually updates this information, and have it done through bindings, any help would be greatly appreciated. Form - For Simplicity i've moved the required parts of the usercontrol into the form
cEntities Context = new cEntities(); Staff s = null; Guid gStaff = new Guid("99772C66-B379-4124-839B-3427AE3481C4"); Guid gRate = new Guid("987E3837-F099-481E-BC5C-544BC04361BC"); public MainWindow() { InitializeComponent(); s = (from staff in Context.Staff where staff.gStaffID == s select staff).First(); DataContext = s; lvwTimeCharges.ItemsSource = (from c in s.Charges where c.Rate.gRateID == gRate select c); } private void child\_ContextRequested(iWantzContext sender, EventArgs e) { sender.Context = Context; } private void button1\_C -
I'm trying to create a lookup that can be used in many places within my application, it is to display a list of activities. It is to be used in several places, each with their own DataContext, as the application dosn't have one static context used by all forms. All instances of the context are from the same Entity Model. The first issue i had was on one form i have a databound list view containing usercontrols as the item template, this user control contained the lookup in question. The lookup needs to share the same context as the form. This was a bit of an issue as i could not find an simple way of doing this, so i created an event in the lookup that requests a context, this is handled by the form. The lookup contains a Dependancy Property called Value, of the type Activity, the user control binds its Activity to the Value, but also shows some other information about the activity, this is where my issue is, this fails to update when the activity is changed. Ideally i would like to avoid any process that manually updates this information, and have it done through bindings, any help would be greatly appreciated. Form - For Simplicity i've moved the required parts of the usercontrol into the form
cEntities Context = new cEntities(); Staff s = null; Guid gStaff = new Guid("99772C66-B379-4124-839B-3427AE3481C4"); Guid gRate = new Guid("987E3837-F099-481E-BC5C-544BC04361BC"); public MainWindow() { InitializeComponent(); s = (from staff in Context.Staff where staff.gStaffID == s select staff).First(); DataContext = s; lvwTimeCharges.ItemsSource = (from c in s.Charges where c.Rate.gRateID == gRate select c); } private void child\_ContextRequested(iWantzContext sender, EventArgs e) { sender.Context = Context; } private void button1\_CAny reason why you're using data binding to bind your control to the data model, but then dropping back to WinForms-style event handling to link the combo box to the containing control?
<ComboBox
DisplayMemberPath="sActivityDescription"
DataContext="{Binding RelativeSource={RelativeSource Mode=FindAncestor,AncestorType=UserControl}}"
SelectedItem="{Binding Value,Mode=TwoWay}"
ItemsSource="{Binding LookupValues}"
/>(Or you could put the actual type of your control there instead of UserControl) To make this nice and clean, change your private "lookupValues" into either a DependencyProperty or one that fires off an INotifyPropertyChanged.PropertyChanged event. That way, the combo is always bound to the Value property, and its ItemsSource is always bound to your internal list. You never have to catch any events from it, and you don't even need to assign a name to it. That's how WPF is meant to be used... Let the bindings do the work, so you never have to worry about keeping things synchronized.
Ed Hill _5_ wrote:
private void child_ContextRequested(iWantzContext sender, EventArgs e)
:laugh:
Proud to have finally moved to the A-Ark. Which one are you in?
Author of the Guardians Saga (Sci-Fi/Fantasy novels) -
Any reason why you're using data binding to bind your control to the data model, but then dropping back to WinForms-style event handling to link the combo box to the containing control?
<ComboBox
DisplayMemberPath="sActivityDescription"
DataContext="{Binding RelativeSource={RelativeSource Mode=FindAncestor,AncestorType=UserControl}}"
SelectedItem="{Binding Value,Mode=TwoWay}"
ItemsSource="{Binding LookupValues}"
/>(Or you could put the actual type of your control there instead of UserControl) To make this nice and clean, change your private "lookupValues" into either a DependencyProperty or one that fires off an INotifyPropertyChanged.PropertyChanged event. That way, the combo is always bound to the Value property, and its ItemsSource is always bound to your internal list. You never have to catch any events from it, and you don't even need to assign a name to it. That's how WPF is meant to be used... Let the bindings do the work, so you never have to worry about keeping things synchronized.
Ed Hill _5_ wrote:
private void child_ContextRequested(iWantzContext sender, EventArgs e)
:laugh:
Proud to have finally moved to the A-Ark. Which one are you in?
Author of the Guardians Saga (Sci-Fi/Fantasy novels)Thanks for your reply, code project seemed to go down for a while yesterday, so was only able to read throug it now. I will give this a try and let you know how it works, or more likly if i have any questions.
Ian Shlasko wrote:
Any reason why you're using data binding to bind your control to the data model, but then dropping back to WinForms-style event handling to link the combo box to the containing control?
In answer to your above question, this is my first project that i have used both entity framework and WPF so i am learning as i go, and unfortunatly when i'm not sure how to do things i fall back on the old win forms way of working. I'll get there in the end its just a but of a learning process for me.
-
Any reason why you're using data binding to bind your control to the data model, but then dropping back to WinForms-style event handling to link the combo box to the containing control?
<ComboBox
DisplayMemberPath="sActivityDescription"
DataContext="{Binding RelativeSource={RelativeSource Mode=FindAncestor,AncestorType=UserControl}}"
SelectedItem="{Binding Value,Mode=TwoWay}"
ItemsSource="{Binding LookupValues}"
/>(Or you could put the actual type of your control there instead of UserControl) To make this nice and clean, change your private "lookupValues" into either a DependencyProperty or one that fires off an INotifyPropertyChanged.PropertyChanged event. That way, the combo is always bound to the Value property, and its ItemsSource is always bound to your internal list. You never have to catch any events from it, and you don't even need to assign a name to it. That's how WPF is meant to be used... Let the bindings do the work, so you never have to worry about keeping things synchronized.
Ed Hill _5_ wrote:
private void child_ContextRequested(iWantzContext sender, EventArgs e)
:laugh:
Proud to have finally moved to the A-Ark. Which one are you in?
Author of the Guardians Saga (Sci-Fi/Fantasy novels)Ok looking back through my origional question it looks like i have said DataContext when i should have been saying ObjectContext. I believe the DataContext is being set through databinding as it should be, its the object context that I was resorting to the old windows way of doing things to pass about. If it helps i have uploaded a copy of a project i am using to test this and a screen shot of the entity model. Object Context Screen Shot Project Zipped
-
Thanks for your reply, code project seemed to go down for a while yesterday, so was only able to read throug it now. I will give this a try and let you know how it works, or more likly if i have any questions.
Ian Shlasko wrote:
Any reason why you're using data binding to bind your control to the data model, but then dropping back to WinForms-style event handling to link the combo box to the containing control?
In answer to your above question, this is my first project that i have used both entity framework and WPF so i am learning as i go, and unfortunatly when i'm not sure how to do things i fall back on the old win forms way of working. I'll get there in the end its just a but of a learning process for me.
Ed Hill _5_ wrote:
In answer to your above question, this is my first project that i have used both entity framework and WPF so i am learning as i go, and unfortunatly when i'm not sure how to do things i fall back on the old win forms way of working. I'll get there in the end its just a but of a learning process for me.
No problem... Sorry if that came off as hostile... Wasn't sure if you had an actual reason for doing it that way - Some situation that data binding couldn't handle. But if you're just new to WPF... Well, we were all new at some point. Took me a while to get the hang of it, but now WinForms seems almost backwards by comparison. Generally, the goal in WPF is to completely separate the GUI from the code-behind... So the GUI knows nothing about the code and the code knows nothing about the GUI. Only the model is shared between them. The only time you should even have to assign a name to a WPF control and refer to it in the code, is for those odd situations where data binding isn't good enough. If the code needs to make a change to the GUI, it should instead be doing something to the model, which the GUI would detect and react to. It sounds unnecessary, but it's actually pretty powerful. For example, a button on the GUI could have its IsEnabled property bound to a boolean property on the model. The property changes and the button is now ready to be used. Sometime later, you could decide to overhaul the GUI and make it flashy and attractive, so instead of just having a button enable itself, you could have the infamous Clippy fly onto the screen and pop up a little speech balloon saying "All set! Click here!", and simultaneously have a custom animated button-type thing light up with blinking text and... well, you get the idea... All of that could be triggered just by setting that single boolean property on the model, and you could do all this without making a single change to the model or the business logic. So in short... I think the Name property is the key... If you find yourself referencing a GUI control by name in the code, you need to take a step back and ask yourself if there's a better way.
Proud to have finally moved to the A-Ark. Which one are you in?
Author of the Guardians Saga (Sci-Fi/Fantasy novels) -
I'm trying to create a lookup that can be used in many places within my application, it is to display a list of activities. It is to be used in several places, each with their own DataContext, as the application dosn't have one static context used by all forms. All instances of the context are from the same Entity Model. The first issue i had was on one form i have a databound list view containing usercontrols as the item template, this user control contained the lookup in question. The lookup needs to share the same context as the form. This was a bit of an issue as i could not find an simple way of doing this, so i created an event in the lookup that requests a context, this is handled by the form. The lookup contains a Dependancy Property called Value, of the type Activity, the user control binds its Activity to the Value, but also shows some other information about the activity, this is where my issue is, this fails to update when the activity is changed. Ideally i would like to avoid any process that manually updates this information, and have it done through bindings, any help would be greatly appreciated. Form - For Simplicity i've moved the required parts of the usercontrol into the form
cEntities Context = new cEntities(); Staff s = null; Guid gStaff = new Guid("99772C66-B379-4124-839B-3427AE3481C4"); Guid gRate = new Guid("987E3837-F099-481E-BC5C-544BC04361BC"); public MainWindow() { InitializeComponent(); s = (from staff in Context.Staff where staff.gStaffID == s select staff).First(); DataContext = s; lvwTimeCharges.ItemsSource = (from c in s.Charges where c.Rate.gRateID == gRate select c); } private void child\_ContextRequested(iWantzContext sender, EventArgs e) { sender.Context = Context; } private void button1\_COk think i have solved the issue i was having, wit the lookupnot updating the control it was on, the cause was only scalars automatically trigger a change notification, the solution was adding the following to a partial class.
public partial class Charge
{
public Charge()
{
this.ActivityReference.AssociationChanged += new System.ComponentModel.CollectionChangeEventHandler(ActivityReference_AssociationChanged);
}void ActivityReference\_AssociationChanged(object sender, System.ComponentModel.CollectionChangeEventArgs e) { if ((e.Action == System.ComponentModel.CollectionChangeAction.Remove)) OnPropertyChanging("Activity"); else OnPropertyChanged("Activity"); } }If any one is able to share a best practice way to make the lookup use the same ObjectContext as the Window is using that would be most helpful. I think the line below outlines the situation i am in, and the aim is for the
cEntities Context = new cEntities();from the window to be used in the lookup when popluating theComboBox.ItemsSource. Window>Databound List View>Item Template>Lookup User Control
