Blog Home  Home Feed your aggregator (RSS 2.0)  
kevin Mocha - DotNet | WPF
Bookmarks collected from web.
 
 Friday, August 15, 2008
 Friday, July 18, 2008
 Wednesday, July 16, 2008

To solve this, we have to manually add the mouse event handler onto the controls and set the handled parameter to true.

this.tbId.AddHandler(TextBox.MouseDownEvent, new RoutedEventHandler(tb_mouseDown), true);

Wednesday, July 16, 2008 10:06:03 PM UTC  #    Comments [0]    |  Trackback

_strandGroup = this.listViewGroups.SelectedItem as StrandGroup;

Wednesday, July 16, 2008 2:33:50 PM UTC  #    Comments [0]    |  Trackback

<GridViewColumn Header="Strand Type">
     <GridViewColumn.CellTemplate>
             <DataTemplate>
                    <ComboBox SelectedValue="{Binding Path=StrandId}" SelectedValuePath="Id" DisplayMemberPath="Name" Width="120" GotFocus="ComboBox_GotFocus" SelectionChanged="ComboBoxStrandType_SelectionChanged"
                                            ItemsSource="{Binding RelativeSource={RelativeSource FindAncestor, AncestorType={x:Type local:LongitudinalStrandGroupsAssist}}, Path=MPrestressedStrands}"/>
             <DataTemplate>
     </GridViewColumn.CellTemplate>
</GridViewColumn>

Wednesday, July 16, 2008 2:32:24 PM UTC  #    Comments [0]    |  Trackback
 Wednesday, July 09, 2008
 Friday, June 20, 2008

From http://dotnet.org.za/rudi/archive/2008/03/25/10-things-i-didn-t-know-about-wpf-data-binding.aspx

 

1) Binding path "(TextBox.Text)" vs "Text"?

If you bind to a path called Text, WPF uses reflection to resolve the name. If you use the class-qualified name, binding avoids the reflection performance hit. Class-qualified names also allows binding to attached properties!

2) WPF doesn't raise exceptions to notify you about data binding problems

All binding errors are output as trace information and NOT exceptions!

Beatriz Costa (Who else) has a excellent article about this

3) Why use OneWayToSource binding mode?

Well, the target object must always be a DP! The most common use of OneWayToSource mode is to by-pass this restriction! The source doesn't need to be a DP and effectively using OneWayToSource reverses the binding direction.

A perfect example is Run, it's text property is not backed by a DP!

4) Default binding mode?

Not all DP's have the same default binding mode!!!

If the binding mode is two-way, but the CLR property that it is bound to is read-only... will cause problems! just keep in mind that you can't assume what the binding mode is!!!

It is always a good idea to explicitly specify your binding mode. Also remember that OneWay is slightly lighter than TwoWay!

5) RelativeSourceMode.PreviousData

If you bind to a collection of prices and need to show the change from the previous price to the current price then this little trick can be very useful... Pass the current item and the following binding into a IMultiValueConverter converter

{Binding RelativeSource={RelativeSource PreviousData}}

The multi value converter now just need to work out what the difference is!

6) RelativeSourceMode.FindAncestor

This is a very cool hack I found... Lets assume that you have a ListBox showing data. Normally if you have a TextBlock inside your DataTemplate and you don't supply it with a foreground color, then it would inherit the parents Foreground property. What is cool about this is that then when you click on the item, the font color would change from black to white! Now assume that your DataTemplate also contains a custom control that do not rely on the Foreground property to determine its color (As a example, I will use a Ellipse which has a Fill and not a Foreground/Background). If I add a Ellipse to this DataTemplate and  I do not set its fill, it would stay blank. Even if I give it a Fill color, it will fill with this color but if I now select this ListBox item, it will stay the provided color!

So how do I make my ellipse inherit the Foreground color and more importantly, how do I make it change to white once selected? Binding its Fill with the following

{Binding RelativeSource={RelativeSource FindAncestor, AncestorType={x:Type ListBoxItem}}, Path=Foreground}

Now, it will inherit the parents Foreground and also change once selected...

7) Binding a ListBox to a custom object, What gets displayed in the ListBox?

When binding to a custom object, determining what is displayed in the ListBox can be one of 3 options

  1. Set the DisplayMemberPath on the ListBox to a path
  2. Create a DataTemplate
  3. Override the ToString() on the custom object. If no DisplayMemberPath or DataTemplate is found, the ToString() is called on the custom object.

8) {Binding Path=/}

Bind to the current item in the view! Just remember to set IsSynchronizedWithCurrentItem to true

[UPDATE] While reading Ian Griffiths blog, I found a entry detailing this behaviour in WPF databinding

9) Binding has a constructor that take Path as a parameter

This is just a small shortcut

{Binding Path=Name}

Can be written like this

{Binding Name}

10) {Binding}

This looks a little weird but all this means is that the source is defined somewhere up the tree... common place is Window.DataContext. By setting the DataContext to a collection, I can now add a ListBox to the visual tree and then binding this ListBox's ItemsSource to {Binding}. This will tell the ListBox that its ItemsSource is the DataContext of the Window!

Friday, June 20, 2008 5:39:03 PM UTC  #    Comments [0]    |  Trackback
 Tuesday, June 17, 2008
 Monday, June 02, 2008

http://geekswithblogs.net/thibbard/archive/2008/05/20/wpf---collectionviewsource-that-updates-automatically.aspx

public class AutoRefreshCollectionViewSource : CollectionViewSource
{
    protected override void OnSourceChanged(object oldSource, object newSource)
    {
        if (oldSource != null)
        {
            SubscribeSourceEvents(oldSource, true);
        }

        if (newSource != null)
        {
            SubscribeSourceEvents(newSource, false);
        }

        base.OnSourceChanged(oldSource, newSource);
    }


    private void Item_PropertyChanged(object sender, PropertyChangedEventArgs e)
    {
        bool refresh = false;
        foreach (SortDescription sort in SortDescriptions)
        {
            if (sort.PropertyName == e.PropertyName)
            {
                refresh = true;
                break;
            }
        }

        if (!refresh)
        {
            foreach (GroupDescription group in GroupDescriptions)
            {
                PropertyGroupDescription propertyGroup = group as PropertyGroupDescription;

                if (propertyGroup != null && propertyGroup.PropertyName == e.PropertyName)
                {
                    refresh = true;
                    break;
                }
            }
        }

        if (refresh)
        {
            View.Refresh();
        }
    }

    private void Source_CollectionChanged(object sender, NotifyCollectionChangedEventArgs e)
    {
        if (e.Action == NotifyCollectionChangedAction.Add)
        {
            SubscribeItemsEvents(e.NewItems, false);
        }

        else if (e.Action == NotifyCollectionChangedAction.Remove)
        {
            SubscribeItemsEvents(e.OldItems, true);
        }
        else
        {
            // TODO: Support this
            Debug.Assert(false);
        }
    }

     
    private void SubscribeItemEvents(object item, bool remove)
    {
        INotifyPropertyChanged notify = item as INotifyPropertyChanged;     

        if (notify != null)
        {
            if (remove)
            {
                notify.PropertyChanged -= Item_PropertyChanged;
            }
            else
            {
                notify.PropertyChanged += Item_PropertyChanged;
            }
        }
    }
     
    private void SubscribeItemsEvents(IEnumerable items, bool remove)
    {
        foreach (object item in items)
        {
            SubscribeItemEvents(item, remove);
        }
    }

    private void SubscribeSourceEvents(object source, bool remove)
    {
        INotifyCollectionChanged notify = source as INotifyCollectionChanged;

        if (notify != null)
        {
            if (remove)
            {
                notify.CollectionChanged -= Source_CollectionChanged;
            }

            else
            {
                notify.CollectionChanged += Source_CollectionChanged;
            }
        }

         
        SubscribeItemsEvents((IEnumerable)source, remove);

    }

}

Using the CollectionViewSource is a good way of binding to a datasource and letting the XAML determine the sorting and grouping of the data. However, as your datasource changes, the grouping and sorting is not automatically "re-calculated", forcing your code to be smarter that it should be. I found a class today on MSDN forums that inherits from CollectionViewSource and adds automatic refresh capabilities. This code is smart enough to resort your items, regroup your items and even add new groupings as needed.
Some good CollectionViewSource links:

Monday, June 02, 2008 7:49:01 PM UTC  #    Comments [0]    |  Trackback
 Thursday, May 29, 2008
 Tuesday, May 27, 2008
 Wednesday, May 21, 2008
 Thursday, April 17, 2008

Databinding issue in WPF: with solution

http://www.lhotka.net/weblog/DataBindingIssueInWPFWithSolution.aspx#a89bf0c78-2bfc-4872-89b3-5499c4cbd0ae

(Important: set UpdateSourceTrigger to LostFocus for textbox)

Thursday, April 17, 2008 7:56:42 PM UTC  #    Comments [0]    |  Trackback
 Tuesday, April 15, 2008
 Tuesday, April 08, 2008

First, make sure the OpenHandCursor.cur file is marked as Resource (not EmbeddedResource) in the referenced assembly.

 

Code Block

 

// use resource in local assembly

// new Uri("pack://application:,,,/folder/filename.cur")

// use resource in referenced assembly

// new Uri("yourAssemblyName;component/folder/filename.cur"
// ,UriKind.Relative)

Stream cursorStream =

Application.GetResourceStream(new Uri    ("CursorLib;component/cursors/help.cur",
UriKind.Relative)).Stream;

this.Cursor = new Cursor(cursorStream);

Tuesday, April 08, 2008 6:11:08 PM UTC  #    Comments [0]    |  Trackback
 Wednesday, March 05, 2008
 Wednesday, February 27, 2008
 Friday, February 22, 2008
 Tuesday, February 19, 2008
 Friday, February 08, 2008
 Thursday, November 08, 2007

Following are some of my observations got from the book:

Chapter 1&2

  • XAML is just a way to use .NET APIs. WPF and XAML can be used independently from each other.
  • XAML specification defines rules that map .NET namespaces, types, properties, and events into XML namespaces, elements, and attributes.
  • Markup extensions are just classes with default constructors.
  • An object element can have three types of children: a value for a content property, collection items, or a value that can be type-converted to its parent.

Chapter 3 Important new Concepts in WPF

Logic Tree

The logical tree concept is straightforward, but why should you care about it? Because just about every aspect of WPF (properties, events, resources, and soon) has behavior tied to the logical tree. For example, property values are sometimes propagated down the tree to child elements automatically, and raised events can travel up or down the tree. Both of these behaviors are discussed later in this chapter.

Visual Tree
A similar concept to the logical tree is the visual tree. A visual tree is basically an expansion of a logical tree, in which nodes are broken down into their core visual components. Rather than leaving each element as a “black box,” a visual tree exposes the visual implementation details. For example, although a ListBox is logically a single control, its default visual representation is composed of more primitive WPF elements: a Border, two ScrollBars, and more.

Dependency Properties

A dependency property depends on multiple providers for determining its value at any
point in time. These providers could be an animation continuously changing its value, a
parent element whose property value trickles down to its children, and so on. Arguably
the biggest feature of a dependency property is its built-in ability to provide change notification.

Change Notification (Property Trigger)   

Property Value Inheritance

Multiple Providers

Attached Properties

Routed Events (routing Strategies:tunneling, bubbling, Direct)

Attached Events

Commands: a more abstract and loosely-coupled version of events.

 

image

Thursday, November 08, 2007 7:22:43 PM UTC  #    Comments [0]    |  Trackback
 Thursday, June 07, 2007
 Wednesday, June 06, 2007

I create this new category for studying WPF.

Wednesday, June 06, 2007 8:52:15 PM UTC  #    Comments [0]    |  Trackback
Copyright © 2008 Kevin Mocha. All rights reserved.
DasBlog 'Portal' theme by Johnny Hughes.
Pick a theme: