|
How do you create a data grid in WPF with multiple bands? I can't find a single example
If it's not broken, fix it until it is
|
|
|
|
|
|
Wonderful.
I'll use 2 grids.
If it's not broken, fix it until it is
|
|
|
|
|
A number of third party tools like Telerik, Infragisitcs provide nested grid s that you could explore for your implementation.
|
|
|
|
|
Hello,
I have the next view XAML file:
<Grid>
<ScrollViewer>
<ItemsControl ItemsSource="{Binding MemControls}"/>
</ScrollViewer>
</Grid>
The ItemsControl binded to:
public ObservableCollection<UserControl> MemControls
{
get { return _memControls; }
set { _memControls = value; }
}
in the view Model.
I want to give the user an option to save GUI configuration. So when he press "Save" button i want to serialize the:
public ObservableCollection<UserControl> MemControls
<pre>
to XML file and when he want to restore GUI configuration i want to to desirialize from an XML file the list of controls and that way to restore GUI configuration.
How can i do it?
Maybe there is some other better way that dont involve XML files?
Thanks
|
|
|
|
|
Although this article [^]is for winforms it may give you some ideas.
I would also check out the comment from Tom Clement and see if he did an article on FormEx.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
|
Hello Listeners,
I created a SL application (using C#) that returns contents of a table in SQL database. Table has 5 columns (FirstName, LastName, Age..etc).
--A grid is populated with following:
EclipseMTXDomainContext context = new EclipseMTXDomainContext();
dataGrid1.ItemsSource = context.DBTables;
context.Load(context.GetDBTablesQuery());
--Mine domain service has an entry as follows:
public IQueryable<dbtable> GetDBTablesCompare() {
return this.ObjectContext.DBTables;
}
This works fine but
What I am trying to do now is load only two columns at a time so I added this in the domain services
public IQueryable<dbtable> GetTwoColms(string db1,string db2) {
return this.ObjectContext.DBTables.Where(P => P.col1Name == cl1 && P.col2Name == cl2);
}
--And the main program, added this to a button action
EclipseMTXDomainContext context = new EclipseMTXDomainContext();
dataGrid1.ItemsSource = context.DBTables;
context.Load(context. GetTwoColms Query("LastNames","FirstName"));
It does not fail but it does not return anything either.
Any help is greatly appreciated
|
|
|
|
|
My first guess:
You have the column names as "LastNames" (plural) and "FirstName" (singular) which looks suspiciously like a typo.
|
|
|
|
|
ThanX Matt,
that is not the issue, it is just careless type when creating the post.
|
|
|
|
|
picasso2 wrote: it is just careless type when creating the post.
Then use Copy & Paste, so what we see here matches exactly with what you have in your program.
Veni, vidi, abiit domum
|
|
|
|
|
u can use lamda method select() return a implicit class consists of u wanted 2 columns
|
|
|
|
|
Hi all
below is my wpf progress bar
Dim duration As New Duration(TimeSpan.FromSeconds(20))
Dim doubleanimation As New DoubleAnimation(200.0, duration)
PBar.BeginAnimation(ProgressBar.ValueProperty, doubleanimation)
Now please tell me how to open a window after the progress bar load complete.. 
|
|
|
|
|
Subscribe to the Completed event[^] on your DoubleAnimation[^] instance, and open the window when the event is raised.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
5ed!
--
If money is your hope for independence, you cannot reach it.
Being loved gives you strength,
while loving gives you courage.
|
|
|
|
|
I am still struggling to understand how to use DP's....
I am designing a Job Picker control[^]. The control is housed inside a Select Job window and also inside a wizard. When the user clicks a Job, I want that job exposed as a DP so the Window or Wizard know that a job was selected.
In the Window, when a Job is selected, the Select button will come on.
So in the control there is the tree:
<controls:TreeViewEx BorderThickness="0"
Margin="5"
ItemsSource="{Binding Jobs}"
SelectedItemEx="{Binding SelectedJob, Mode=TwoWay}"
IsManipulationEnabled ="True"/>
It's bound to Jobs and has it's SelectedItem bound to SelectedJob:
The JobListControl's VM is JobListViewModel:
#region Bound Properties
private ObservableCollection<JobSummaryModel> _Jobs;
public ObservableCollection<JobSummaryModel> Jobs
{
get { return _Jobs; }
set
{
if (_Jobs == value)
return;
_Jobs = value;
RaisePropertyChanged("Jobs");
}
}
private JobSummaryModel _SelectedJob;
public JobSummaryModel SelectedJob
{
get { return _SelectedJob; }
set
{
if (_SelectedJob == value)
return;
_SelectedJob = value;
RaisePropertyChanged("SelectedJob");
}
}
#endregion
This all works fine. When I click a Job in the tree, the SelectedJob property fires. So far so good.
Now, I need to expose the SelectedJob to the control's host (either the SelectJob window or the Wizard). So I went into the code behind and added a DP:
public partial class JobListView : UserControl
{
public JobListView()
{
InitializeComponent();
}
#region SelectedJob DP
public JobSummaryModel SelectedJob
{
get { return (JobSummaryModel)GetValue(SelectedJobProperty); }
set { SetValue(SelectedJobProperty, value); }
}
public static readonly DependencyProperty SelectedJobProperty = DependencyProperty.Register("SelectedJob", typeof(JobSummaryModel),
typeof(JobListView));
#endregion
}
Next, in the Window's XAML I have:
<views:JobListView Grid.Row="0"
SelectedJob="{Binding Path=SelectedJob, Mode=TwoWay}"/>
The SelectJobWindowViewModel has a SelectedJob property of the same type as the JobListViewModel above;
The SelectJobWindowViewModel.SelectedJob property never fires.
I guess I was expecting the DP to pass the Selected Job from the control through to the Window.
Wat am I not seeing here?
Thanks
If it's not broken, fix it until it is
|
|
|
|
|
First of all your property should be static, like this;
public static JobSummaryModel SelectedJob
|
|
|
|
|
I tried it, but it won't compile. I get
An object reference is required for the non-static field, method, or property 'System.Windows.DependencyObject.SetValue(System.Windows.DependencyProperty, object)'
Same on the getter.
If it's not broken, fix it until it is
|
|
|
|
|
Pete must have been smoking some really good dope when he answered you  . Your code is correct how you have it. I'm assuming you got rid of the:
private JobSummaryModel _SelectedJob;
public JobSummaryModel SelectedJob
{
get { return _SelectedJob; }
set
{
if (_SelectedJob == value)
return;
_SelectedJob = value;
RaisePropertyChanged("SelectedJob");
}
}
stuff and REPLACED it with:
public JobSummaryModel SelectedJob
{
get { return (JobSummaryModel)GetValue(SelectedJobProperty); }
set { SetValue(SelectedJobProperty, value); }
}
public static readonly DependencyProperty SelectedJobProperty = DependencyProperty.Register("SelectedJob", typeof(JobSummaryModel),
typeof(JobListView));
??
The key point here that everybody seems to be forgetting is that DPs don't go through the C# getter / setter (when binding). That is only there to make it easier to get/set the DP from the code. Your SelectedJob method is *COMPLETELY* bypassed by the binding system.
Use one of the DependencyProperty.Register overloads that take a property changed callback. That is the ONLY way you can determine when a DP value changes.
|
|
|
|
|
I thought I read in the OP's first message that he put the DP code in the code behind for the page. We should point out that the DP code and the property should both be defined in the view model. Nothing should be in the code behind!
|
|
|
|
|
First, I don't agree with the "Nothing in the code behind" mantra.
Second, if the DP is in the VM, then how does the control's host see it? It won't.
If it's not broken, fix it until it is
|
|
|
|
|
Whether you agree with it or not, it doesn't change the fact that is the accepted method of implementing MVVM. They aren't called best practices because somebody arbitrarily thinks there shouldn't be code in the code-behind. There are very few instances where code in the code behind is the only option. And putting the DP implementation in the code behind is not one of those times.
Secondly, do you actually know how the DP system works and how the property binding system works? Do you even know why you use dependency properties? Your comments make me think not. The DP system is pubic and static... it is accessible from anywhere in your code. The binding framework knows how to find the DP if the underlying property has been registered with it. Normal developers put the DP code in the view model so it only gets instantiated once. But you probably don't agree with that mantra either.
You seem sure that the control can't see the DP unless it is in the code behind but the dozens of programs I've written in Silverlight, WPF, WinRT, and Windows Phone all seem to work perfectly fine without a single DP in a code behind. And for the life of me, I can't find any real examples of someone suggesting that it goes in the code behind. Clearly I must be doing something wrong...
|
|
|
|
|
1) I started my original post with "I'm still struggling to understand DP's", so, no, I don't understand DP's, hence my post.
2) Your comments on the 'accepted method of implementing MVVM' are subjective. Just because I don't fully understand DP's doesn't mean I also don't understand WPF/MVVM. I've been doing MVVM for a long time with no problems. I just haven't used DP's and I thought I needed one here.
MVVM simply calls for a separation of concerns. So what concerns are we talking about? Data vs UI.
There's no law that states you can't put code in the code behind. The MVVM principle would not be violated if the code in the code behind was UI related. Do some Googling on "MVVM Code IN Code Behind" and you'll see lot's of discussions on folks putting UI code in the code behind to make their UI more functional.
Having said all that, I personally try to avoid code in the code behind simply because I don't see a need for it, and also because I don't want code in 2 places. But that doesn't make me a purist in any sense.
3) I'm not sure what you mean by "Normal developers put the DP code in the view model so it only gets instantiated once. But you probably don't agree with that mantra either."
a) I am a 'Normal developer' (I'm confused by this comment)
b) If the DP was in the View or VM - what would make it instantiate more than once?? My view's code behind and my VM's only ever instantiate once each. Again, confusing statement
I'm totally open to putting the DP in the VM. But when I've done that in the past it doesn't show up in the XAML. My JobListView control has the DP in the code behind. Therefore it's compiled into the same component. You of course know that the XAML and Code Behind are one, so putting the DP in the code behind allows it to be visible in the XAML of the view hosting the user control:
<views:JobListView Grid.Row="0"
SelectedJob="{Binding Path=SelectedJob, Mode=TwoWay}"/>
In this case, 'SelectedJob' is the DP defined in the JobListView code behind. Move the DP to the VM and this XAML is broken.
Again, all this is based on my limited knowledge of DB's. I have yet to see a decent tutorial on how to USE them. Not DEFINE them - USE them. There's a difference.
Thanks
If it's not broken, fix it until it is
|
|
|
|
|
I see I was getting a bit snarky in the previous reply. Sorry about that... I shouldn't do that. Please accept my apologizes.
Now, onto your questions...
MVVM is about separation of concerns but it is the WHY that really drives the structure. The idea is that if you remove "backward" dependencies, then you can swap layers in and out or reuse them. So the view depends on the view model but you can't have anything in the view model depend on the view. Similarly, the view model depends on the model (if implemented) but the model can't depend on the view model at all. If implemented this way, you can reuse the code at the VM and M levels. A single model could support multiple VM's. A single VM could support multiple views. Imagine, for a second, that you had an app that the main view displayed a list of customers. Supposed that your default view was a grid listing of those customers. What if you wanted to show them as tiles that could be rearranged? That would probably be best done in a different view. While you would only have one active view at any time, both views would bind to the same view model where you would maintain the data and the state. For example the "selected" customer shouldn't change if the user simply changes views. If you put anything that is outside of the scope of a single view in the code behind, then you have issues of scope and possible coupling between your view(s) and your view model(s). That is the reason to avoid putting code in the code behind. It is easy to say that it is no big deal when you have a 1 to 1 to 1 mapping. But it becomes a big deal when that changes. So the best practice is to avoid it so you don't have to go back and refactor if something changes.
And... that really answers the questions about dependency properties. DP's are used by the binding system to hook-up properties between two classes for automatic synchronization. If you are going to bind two properties (which is what you are doing with the selected row on the treeview and the corresponding property on the view model) then ONE of them has to be a dependency property. So a DP hooked to a DP will work. A DP hooked to a regular property will work. But a regular property hooked to a regular property will not work. The binding framework in this case, can't resolve the property name raised in the propertychanged event because the framework uses the dependency property system to resolve the property names and update the values.
The DP system is a static class so there is one instance of it for your application and it is automatically created the first time it gets called. Think of it as an impartial 3rd-party. If you look in the sample code provided in one of the other answers you will see where the public SelectedJob property gets registered (via the Register method of the DependencyProperty static class) with the DP system. The DP system now knows about the SelectedJob property on your view model. We usually pair the DP registration code up with the property code in the view model because the getter and the setter for the property must now GetValue and SetValue the backing dependency property. Once registered as a DP, the regular public property uses the DP system as the backing store so it is really just a proxy to make it easier to code against. The presence of the public property lets you write:
SelectedJob = new myJobClass;
rather than:
SetValue(SelectedJobProperty,value);
More importantly, the public property allows you to set the binding in xaml in a format that makes sense. So your SelectedJobs dependency property can be bound with:
<treeview SelectedItemEx = {Binding SelectedJob, mode = TwoWay} />
The binding system looks in the Dependency system to find SelectedJobProperty (the DP object for the SelectedJob property) at runtime to handle property updates.
The upshot of all of this is that the dependency system matches up the properties at runtime providing a level of indirection between the VM and the view. Because the VM depends on the DP system and the view depends on the DP system, they don't depend on each other and you achieve the separation we are after. The same sort of system is used for commands to go the other way (from the view to the viewmodel).
Since the base property we want to link up is exposed on the view model, we typically pair the DP code up with the property in the view model code. Since the VM only gets instantiated once, we can be sure that the DP only gets registered once. If we put the DP code in the code behind, we couldn't use the DP until the view was instantiated. Back to our example of where we have two views and one view model... now it suddenly doesn't work to put the DP code in the code behind. Do we put it in the first view or the second? Do we put it in both? What happens if we do that? How do we keep from getting an exception thrown because the property is already registered with the DP system? We avoid all of those questions by putting the DP code with the property we are registering in the view model.
Since the DP system is a static third-party and the binding system already knows how to locate it and use it, there is no concept of scope to worry about. Even though we put the code for the DP in the view model, all we are doing is calling the register function and passing in the property information. Technically we could put that anywhere and as long as the VM was instantiated before the call to register, it would work. Mull on that for a moment... you could technically create an instance of your VM in the app.xaml.cs code behind and put the call to register the property with the DP system right after it and it would still work. That goes against convention and it would make it tougher to maintain the code, but it would work.
So my initial statement that the DP code should be in the view model is a best practice and not a rule that is caused by some limitation in the framework. And you most certainly can put it in the code behind. But I hope you can see there are good reasons to pair it with the property on the view model.
Now, with all of that said, I'll probably ruin your day. Remember when I said that ONE property in the equation had to be a DP for the binding to work? The SelectedItemEx on the TreeView is probably already a DP based on the fact that the property on your view is being set when you click on a job. You can bind a property on ANY OTHER CONTROL to that same property on the view model provided the control's property you are hooking up is a DP (and most all of them are). Making the property on your VM a DP will not solve your scope problem and somehow make it available everywhere else. The binding system will ONLY look for properties scoped to the current data context. You need to manage the data context of the host and the wizard to get to the selectedjobs property.
Assuming you have a separate view model for the host and one for the wizard, they need references to the view model that contains the selectedjob. If you are using the MVVM light framework, you can use the Locator class to get the instance of the job view model in the other two view models. Otherwise, you need to create a public static instance of that VM in the app code behind or the main view (host?) code behind and pass it to the constructor of the host VM and/or the wizard VM exposing it as a property on those two view models. Then the selected job (to the host) becomes
hostViewModel.jobViewModel.SelectedJob
The binding would then be:
hostControlProperty = {Binding Path=jobViewModel.SelectedJob}
Assuming hostControlProperty is a DP, there is no need to make SelectedJob on the view model a DP. Indeed, if this is your structure, you MUST have a reference in the host to the VM containing the property regardless of whether it is a DP or not.
The same would be for the wizard. You would need a reference to the job view model in the wizard view model to get access to the property.
Finally, if you don't want to do that... maybe the selected job is the only thing you need... I suggest creating a static class or one using the singleton pattern that exposes a SelectedJob property and implements INotifyPropertyChanged. Use it as the backing store in your view models. Then you have one, global instance of the SelectedJob and you can expose it as a property on any view model you want.
HTH,
Jason
|
|
|
|
|
First, not apology needed. I'm not offended. On the contrary, I don't mind being educated from time to time
So I've read about half of this so far. I'm trying to digest it. It's one of the better explanations of DP's I've read so far.
So I created a 5 minute sample app[^]. The goal is to have the Main Window know when a Client in the user control is selected.
I learn best by doing, but I'm clearly both confused & wrong. Can you show me where the DP(s) go here and how to wire them up?
Let me finish your response and I'll reply soon.
Many thanks!
If it's not broken, fix it until it is
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
