Archive | WPF RSS feed for this section

Why we Blend & Custom combo boxes

5 Feb

I have been sceptical of Expression Blend for a while now. I have found that it is was a marginally better designer than Visual Studio and I didn’t see what the fuss was about. Yesterday I found out a massively powerful feature that now I wouldn’t develop WPF without. The feature I am talking about is the ability to copy existing styles from framework controls such as  a combo-box and change them. This is best demonstrated at the following blog: http://www.designerwpf.com/2008/10/01/how-to-use-a-listview-or-datagrid-in-a-combobox-drop-down-without-a-line-of-code/. For that blog tutorial you don’t need to add a reference like the tutorial asks if you aren’t going to use a datagrid control.

One thing to be careful of is that there will be two item presenters in the template. If you are like me and wanted to make a customizable combo-box drop down but also have the selected item area update then you will need to make your control isEditable=true and isReadOnly=false. This will use the opposite ItemPresenter once isEditable is changed to true. This initially gave me a fright thinking that I would not be able to use isEditable.

If multiple selection is wanted in your custom combo box you can try: http://jobijoy.blogspot.com/2009/02/simple-multiselect-combobox-using.html

Advertisements

Docking WPF controls to right or bottom of a Canvas

28 Jan

When first learning WPF one thing that stumped me was docking controls to the right hand side of a canvas. As I understand WPF layouts, the only default WPF control that allows controls to overlap is the canvas layout control (See comments about a correction here. The canvas control is not the only control that allows items to overlap). This is why I was forced to use the canvas layout (as I wanted the ability to place controls over the top of each other).

The way to solve this issue was to use a multibinding and a multibinding converter. I have provided a code sample below showing a treeview control that is docked to bottom right side of a wpf window.

<TreeView x:Name="Menu" DataContext="MenuData" Height="350" Width="220">
  <Canvas.Left>
    <MultiBinding Converter="{StaticResource RelativePlacementConverter}">
      <Binding ElementName="MainCanvas" Path="ActualWidth" />
      <Binding ElementName="Menu" Path="ActualWidth" />
    </MultiBinding>
  </Canvas.Left>
  <Canvas.Top>
    <MultiBinding Converter="{StaticResource RelativePlacementConverter}">
      <Binding ElementName="MainCanvas" Path="ActualHeight" />
      <Binding ElementName="Menu" Path="ActualHeight" />
    </MultiBinding>
  </Canvas.Top>
</TreeView>

public class RelativePlacementConverter : IMultiValueConverter

{

#region IMultiValueConverter Members

public object Convert(object[] values, Type targetType, object parameter, System.Globalization.CultureInfo culture)

{

double? screenWidth = values[0] as double?; //parent width

double? menuWidth = values[1] as double?; //own width

if (screenWidth != null && menuWidth != null)

{

return (screenWidth – menuWidth);

}

return 0.0;

}

public object[] ConvertBack(object value, Type[] targetTypes, object parameter, System.Globalization.CultureInfo culture)

{

throw new NotImplementedException();

}

#endregion

}

The previous code uses the width and height of the treeview control called Menu and subtracts that from the width and height of the canvas called MainCanvas. For more usecases or more depth on how to implement a multibinding I recommend the following: wpf-tutorial-using-multibindings.

I would recommed using multibindings when a value needs to be result of a combination of other values. There are other ways around this issue without using a multibinding. Links to APIs to avoid multibindings are avalible at: http://marlongrech.wordpress.com/2008/02/10/embed-code-in-xaml/. I like the idea of avoiding multibindings as they take a bit more effort that should be required for simple scenarios like this blog post, however I am also sceptical of alternatives because they don’t yet seem to leverage the power of code behind the way that the multivalueconverter allows.

First Post – Learning WPF

20 Sep

I have finally decided to make a blog because of all of the interesting things I am learning with .NET 3.5 and WPF.

Learning the WPF way of doing things can be quite challenging as you need to drop the poisonous mindset of Winforms to not fall into WPF anti-patterns. I recommend the following links and tips to learn WPF. Follow these and you will learn WPF quicker that I did. I must confess that i fought the idea of these concepts initially but I couldn’t achieve a reasonable design in terms of architecture with out them. Life is miles easier having taken the WPF plunge.

http://www.mindscape.co.nz/blog/?p=69 This tutorial shows how the underlying behavior of a control is more important than how the control renders items. It also shows datatemplates which remove the need to extend controls to change the appearance. It is important to consider that listbox provides selectable item behavior and it binds to a list collection. How it displays data is irrelevant as it can be changed.

http://www.nikhilk.net/Silverlight-ViewModel-Pattern.aspx (This tutorial shows how the traditional MVP is better replaced by a new model. The first links code sample generally follows this design pattern.

I should also point out that I have seen many people try to extend WPF controls. This is not particularly a great idea as you don’t seem to be able to extend multiple levels of inheritance. What you are better to do is to databind your Xaml control to an BaseClass such as Quake (see the first link for example). Then you can extend Quake, by making a class BigQuake. If you add BigQuake to the list that is the datacontext of the listbox, you can use a complex object model with many levels of inheritance without extending any XAML classes. This seems to be a common issue bought up by people first learning XAML because the mindset tends to be to extend a control to change its behavior. This should be a last resort in WPF.

Resource dictionaries can be used to provide centralized themes for your application controls.

A common usecase for businesses to migrate to WPF is the concept of streaming User Interfaces. This is due to the fact that XAML is an XML syntax so it is easily serializable. If you wish to do this, you really must attempt to embrase true WPF thinking otherwise the task will not be simple.

DependencyProperties seem like a nightmare when first learning WPF, there is no Textbox1.Text anymore. Its Textbox1.SetValue(TextBox.TextProperty, “text goes here”); . It is important to learn depenedency properties. A good link to do this is: http://blog.paranoidferret.com/index.php/2008/03/07/wpf-tutorial-introduction-to-dependency-properties/
Another point of interest for people migrating to WPF from Winforms is that you should endevour to put as much as you can into XAML. Almost anything in the codebehind of a WPF Usercontrol tends to be due to laziness of not learning the proper XAML to do it. I do concede however that it is not always possible to avoid using code behind. I am for example at a loss as to how to bind my code to zoom to the current Mouse position with out resorting to code.