I have a view with some controls and a viewbox. At the moment in the viewbox is a grid and a graphic at the bottom. The application reads a XML-file and refreshs the content of the grid and the graphic for every node in the XML-file.
Now the application not only have to show a grid with a graphic. Depending on the XML-node, the application should show a grid with a graphic like now or a grahpic and at the bottom 2 lines of text.
You explained what your application is, but you didn't ask a question. Please state the question, and I can try to give you a better answer.
My best guess is "how do I do that? Do I need to write a custom control?" If that is what you are asking, you probably don't.
Usually you don't need a custom control to make a specialized view for a listbox, listview, or gridview. You can often use data templates, control templates or styles to achieve what you are looking for.
I am not sure if this is a good resource, but the XAML looks like it may be a good starting point for learning how to do control templates:
http://ligao101.wordpress.com/2007/07/27/customizing-listview-in-wpf-part-i/
Simply googling for any of those terms ("ListView data template", etc) will probably get you some good information.
Edit:
From the comments, you are trying to support one of two types of data in the same space in the UI, depending on what is in your XML file:
Image Only
Image, plus two lines of text
One way to solve this would be to create a view model for your XML items, and bind the items to those view models:
public class XmlItemViewModel // Call this something more appropriate to your app
{
public Visibility TextVisibility { get; set; }
public string Text1 { get; set; }
public string Text2 { get; set; }
public Image Picture { get; set; }
}
If you already have a different class that has this data, keep it, and make the view model read properties off that class.
Bind the XAML TextBlock Visibility property to "{Binding TextVisibility}", and it should work. If you set the viewmodel property "Visibility.Collapsed", the text blocks will go away, and your ViewBox should shrink to fit only the image.
If you do this, you don't need a custom control, just a custom ViewModel class.
If it doesn't seem to collapse correctly, you could wrap your image and text blocks with a StackPanel or WrapPanel.
Related
In a DataGrid view, the blank row add entries is convenient but quickly get's lost when the list is large. Can you change it's default location from the bottom to the top of the DataGrid view?
I've rarely used a DataGrid and know nothing about its ability to add rows, but coming from a WPF/MVVM point of view, you don't need that anyway. Generally in WPF/MVVM, we manipulate data rather than UI controls, so the solution is easy. First we Bind our collection of data (in whatever shape we chose) to the DataGrid.ItemsSource property:
public ObservableCollection<DataItem> SomeDataCollection { get; set; }
...
<DataGrid ItemsSource="{Binding SomeDataCollection}" ... />
Now, if we want to add a new item to the bottom of the DataGrid we can do this in the code behind/view model:
SomeDataCollection.Add(new DataItem());
Then if we want to add a new item to the start of the collection, we can just do this:
SomeDataCollection.Insert(0, new DataItem());
Of course, you'll need to implement the INotifyPropertyChanged interface in your code behind/view model to make this work, but (hopefully) you'll be doing that anyway.
UPDATE >>>
Sorry, I misunderstood you. I found a NewItemPlaceholderPosition Enumeration on MSDN that is used by an ItemCollection.IEditableCollectionView.NewItemPlaceholderPosition Property. Unfortunately, those linked pages don't have an code examples, so I found one in the in wpf datagrid how to get the blank row on top? post here on StackOverflow. From the answer by #woodyiii in that post:
var view = CollectionView.GetDefaultCollectionView(EmployeeList)
as IEditableCollectionView;
if(view!=null)
view.NewItemPlaceholderPosition = NewItemPlaceholderPosition.AtBeginning;
This does mean that you'd have to use a CollectionView to get this to work, but it seems like the only way... the NewItemPlaceholderPosition Enumeration isn't used by anything apart from the various CollectionView classes.
This worked for me:
IEditableCollectionView cv = (IEditableCollectionView)grdSchedule.Items;
cv.NewItemPlaceholderPosition = NewItemPlaceholderPosition.AtBeginning;
Where grdSchedule is the the name of your DataGrid
I may be missing something about the fundamentals of WPF design, but I was wondering why many properties on WPF controls are exposed as the type 'Object'?
For example, MenuItem.Icon is an Object, and so is MenuItem.ToolTip. As a near first time user, this was very confusing to me (it felt like I was using a dynamic programming language, having no idea whether setting ToolTip to a String type would even work or not). Moreover, I tried to set the Icon to a 'System.Drawing.Icon' and I get an ArgumentException of "Argument 'picture' must be a picture that can be used as a Icon." Shouldn't the property be typed so it can at least describe what in the world you're supposed to give it?
Honestly, my guess as to the reason is because you cannot implement an interface on a type you did not create (without creating a wrapper), but that's just a guess.
Thanks very much for your answers and insights!
The main reason in my opinion is that since an Object is the "ultimate base class of all classes in the .Net Framework". This gives you flexibility, in WPF you are not limited to a predefined type. Wpf is different and has a learning curve, but it does give you a lot more options to create a product that looks good.
i.e.
You can assign a TextBox to a ToolTip:
TextBox tb = new TextBox();
tb.Text = "Hello World";
this.ToolTip = tb;
a Bitmap
BitmapImage myBitmapImage = new BitmapImage(new Uri((#"C:\Temp\20100706.jpg")));
Image image = new Image();
image.Source = myBitmapImage;
this.ToolTip = image;
and assigning a Image to a MenuItem
BitmapImage myBitmapImage = new BitmapImage(new Uri((#"C:\Temp\20100706.jpg")));
Image image = new Image();
image.Source = myBitmapImage;
menuItem1.Icon = image;
Consider the ToolTip for example. A ToolTip is a ContentControl, which can contain any type of CLR (Common Language Runtime) object (such as a string or a DateTime object) or a UIElement object (such as a Rectangle or a Panel). This enables you to add rich content to controls such as Button and CheckBox.
For this reason, elements such as ToolTip are exposed as Object, that is the root of the type hierarchy (with resulting ease of use, flexibility and clarity of the code).
Imagine these properties were typed as UIElements (or some other WPF specific object). How would you add objects to your controls that were not UIElements?
You would have to provide a wrapper derived from a WPF object that exposes the information you require. Most of the time the wrapper would simply call ToString() of the object being wrapped. Seeing as most types you will be using provide a good enough default implementation of ToString() it makes sense to just call this instead of making the developer write wrappers for everything.
Second, imagine if they were typed as some interface. What if you want to communicate something that this interface can't? The only options are (a) the developer lives with the limitations of the framework or (b) Microsoft updates the interface and breaks all existing code which has already been written.
Also consider if you are using a pattern like MVVM. The current design means your view models can expose properties that are not tied to WPF in any way which ultimately makes your code more reusable across different technologies.
Finally, remember that there is a difference between the object that represents the property and they way that WPF renders that information. E.G. if you use a primitive type such as System.String, WPF will create a textblock and set the text property to the result of ToString(). This allows a very clean separation between the data that is displayed by the UI and they way the information is rendered by the UI.
Take a simple class that represents a menu item, for example:
public class MenuItem
{
public string Text { get; set; }
public bool IsChecked { get; set; }
public bool IsEnabled { get; set; }
}
This type only exposes data about the menu item and has no information about how this information should be rendered. In fact, apart from the name of the class (MenuItem) this is not even specific to a menu item and the same data could be used in another UI control such as a checked listbox with no changes required. If the class exposed WPF specific user interface elements then the information would need to be adapted by another type for each different user interface control.
I'm working on my first project in WPF/XAML, and there's a lot I've not figured out.
My problem is simple - I need a window that has a bunch of fields at the top, with which the user will enter his selection criteria, a retrieve button, and a data grid. When the user clicks on the button, a query is run, and the results are used to populate the grid.
Now the simple and obvious and wrong way to implement this is to have a single module containing a single window, and have everything contained within it - entry fields, data grid, the works. That kind of mangling of responsibilities makes for an unmaintainable mess.
So what I have is a window that is responsible for little more than layout, that contains two user controls - a criteria control that contains the entry fields and the retrieve button, and a data display control that contains the data grid.
The question is how to get the two talking to each other.
Years back, I would have added a function pointer to the criteria control. The window would have set it to point to a function in the display control, and when the button was clicked, it would have called into the display control, passing the selection criteria.
More recently, I would have added an event to the criteria control. I would have had the window set a handler in the display control to listen to the event, and when the button was clicked, it would have raised the event.
Both of these mechanisms would work, in WPF. But neither is very XAMLish. It looks to me like WPF has provided the ICommand interface specifically to accommodate these kinds of connection issues, but I've not yet really figured out how they are intended to work. And none of the examples I've seen seem to fit my simple scenario.
Can anyone give me some advice on how to fit ICommand to this problem? Or direct me to a decent explanation online?
Thanks!
MVVM is the prevalent pattern used with WPF and Silverlight development. You should have a read up on it.
Essentially, you would have a view model that exposes a command to perform the search. That same view model would also expose properties for each of your criteria fields. The view(s) would then bind to the various properties on the view model:
<TextBox Text="{Binding NameCriteria}"/>
...
<Button Command="{Binding SearchCommand}".../>
...
<DataGrid ItemsSource="{Binding Results}"/>
Where your view model would look something like:
public class MyViewModel : ViewModel
{
private readonly ICommand searchCommand;
private string nameCriteria;
public MyViewModel()
{
this.searchCommand = new DelegateCommand(this.OnSearch, this.CanSearch);
}
public ICommand SearchCommand
{
get { return this.searchCommand; }
}
public string NameCriteria
{
get { return this.nameCriteria; }
set
{
if (this.nameCriteria != value)
{
this.nameCriteria = value;
this.OnPropertyChanged(() => this.NameCriteria);
}
}
}
private void OnSearch()
{
// search logic, do in background with BackgroundWorker or TPL, then set Results property when done (omitted for brevity)
}
private bool CanSearch()
{
// whatever pre-conditions to searching you want here
return !string.IsEmpty(this.NameCriteria);
}
}
I'm about to redo an old WinForms application as a WPF application. The core of this applicaton is a custom "grid" component. I'd like some ideas on the best way to do this as a WPF component.
The application displays a grid of data for different countries/sectors. Each cell of the grid displays different information (e.g. graph, image) depending on the available data for that country/sector.
I have a domain model assembly that I want to keep clean - to maximize reuse. The structure is as follows:
Table
Continents
Countries
Sectors
Data[country, sector]
The grid displays countries down the left and sectors across the top.
In the current application, the grid component has a (POCO) Table property and an Refresh() methods to manually redraw it. So, if the Table is updated, the parent of the grid component refreshes it. The grid component also has a number of events that are fired if a continent, country or cell is clicked - so that the parent can response with pop-up menus, etc.
This all works fine.
However, I'm wondering whether this is the correct model to use for a WPF application. Looking at many of the WPF example, they support data-binding, etc. But, it's not clear, from the simple examples, how I might bind a complex object to my components - or whether it would even be worthwhile.
Also, the WinForms component is completely custom drawn - there are no sub-controls (e.g. Labels) in use. Would it be better to use a WPF user control and build the table from a GridLayout and lots of Label, Shape, etc controls? In practice, they are maybe 20 rows and 20 columns in the grid, and the user regular removes and adds countries/sectors (rows/columnms) while using the application.
My immediate goal is to make sure my design plays well in the WPF eco-system, but I have a secondary goal of learning how to do things in a WPFy way - given this is my first WPF app. I'm pretty on top of the use of building a general WPF app - it's just the custom control stuff that remains a little fuzzy (even after reading around it a little).
Any insights/guidance would be appreciated.
You definitely want to adapt the MVVM approach, as outlined by Josh Smith. Practically, this means that your custom grid component will be contained in it's own View. Backing the view will be your ViewModel, where you will define an ObservableCollection of objects containing your data. These objects will probably come from your Model. This interaction is shown below:
Models:
public class TableData
{
public string Country { get; set; }
public string Continent { get; set; }
public object Sector { get; set; }
}
public class TableManager : ITableManager
{
public Collection<TableData> Rows;
public void GetData()
{
this.Rows = new Collection<TableData>();
this.Rows.Add(...
}
}
ViewModel:
public class TableViewModel
{
private ITableManager _tableManager;
public TableViewModel() : base(new TableManager())
{
}
// for dependency injection (recommended)
public TableViewModel(ITableManager tableManager)
{
_tableManager = tableManager;
_tableManager.GetData();
}
public ObservableCollection<TableData> Rows
{
get { return _tableManager.Rows; }
}
}
View:
<ctrls:CustomDataGrid
ItemsSource={Binding Rows}
AutoGenerateColumns=True
>
<!-- Use AutoGenerateColumns if the # of sectors is dynamic -->
<!-- Otherwise, define columns manually, like so: -->
<DataGridTextColumn
Width="*"
Header="SectorA"
Binding="{Binding Country}
/>
</ctrls:CustomDataGrid>
I used CustomDataGrid in the view because I assume you're going to subclass your own DataGrid. This will allow you to override events to customize the DataGrid to your liking:
public class CustomDataGrid : DataGrid
{
public override Event...
}
I am currently working on a new project of mine that is going to be a data record visualizer (for records in Pascal). It should provide a way to define a given record with data fields and pointer fields and then there will be an example view where you can see the record "in action".
Now the problem I am having is that in this model there are records and components and the relationship between them is that one record has multiple components (data and pointer as mentioned above).
I want to use MVVM for the app but I am now unsure how I should approach this. I modelled the record and components into RecordViewModel and ComponentViewModel (with derivates DataComponentVM, PointerComponentVM).
Now to provide a look for these VMs there are 2 options as far as I know:
Deriving the ViewModels from Control and providing a ControlTemplate
Creating a UserControl using the ViewModel as DataContext
The UserControl approach works fine for the RecordViewModel but when I try to design the way the ComponentViewModels are shown (in a ContentPresenter) this approach fails because I would need to provide a collection of UserControls (instead of DataComponentViewModels) in my RecordViewModel that would make that work (and I am pretty sure that is not a good idea).
The Control approach also has the problem that the ViewModels aren't POCOs anymore which I think has a strange feel to it and is also not considered good practice.
Is there any other way to solve the problem? Do you have any other good advice for me in this regard?
Thanks in advance!
Code:
public class RecordViewModel : BaseViewModel
{
public RecordViewModel()
{
Components = new ObservableCollection<ComponentViewModel>();
}
public ObservableCollection<ComponentViewModel> Components { get; set; }
}
public class DataComponentViewModel : ComponentViewModel
{
public string Type { get; set; }
}
public class PointerComponentViewModel : ComponentViewModel
{
public object Target { get; set; }
}
Oh god why didn't I think of this before?
I was only thinking about ControlTemplates (therefore needing my ViewModels to derive from Control) when there are also DataTemplates that work exactly like I wanted them to.
I got lost as to why you think you need to provide a collection of user controls, but it sounds like what you really want is for the RecordViewModel to have some variation of:
ObservableCollection<ComponentViewModel> Components
Components is then bound in xaml to the ItemsSource property of some sort of ItemsControl. Whether or not the ComponentViewModel needs it's own UserControl depends on what you are trying to do with it.
If that doesn't start to click for you then you may want to post some code so we can sort it out.