Data Templates Implementation Outside of WPF

CodeProject

Code Location

The code for this blog post can be downloaded from
NonWPFDataTemplatesTests.zip.

Introduction

Here I continue a series of blog posts regarding implementing WPF
concepts outside of WPF.

WPF is built around a hierarchy of visual objects the so called
Visual Tree. Any WPF control can provide an example of such hierarchy –
e.g. a WPF window might contain a grid panel which in turn contains
a number of visual objects e.g. buttons and list boxes which in turn contain
some text etc.

The object hierarchy is usually built in XAML with the help of numerous
techniques such as bindings, Control Templates and Data Templates.
Data Templates with the help of bindings
allow to translate some non-visual objects into visual objects with the
hierarchy defined by XAML. These resulting visual objects usually mimic the behaviors of the original non-visual objects – e.g. Changing a property on a
non-visual object would result in the corresponding visual property change,
adding or removing an object to or from an observable collection would result
in a corresponding item being added or removed from e.g. a ListView.

This blog entry will show how to use concepts similar to WPF Data Templates
outside of WPF and apply them for creating in XAML purely non-visual objects.

I’d like to stipulate that the utility of the concepts introduced
here might not be quite obvious yet. The usage of non-visual data templates
will be explained in the future blog posts.

Also I would like to express gratitude to the WPF re-implementation attempt
called Avalonia. It would have taken me much longer to understand the inner workings of XAML
functionality without this project and also I am using a modified version of several of its classes: AvalonXamlReader, ContentLoader and TemplateContent in order to create the
non-visual Data Templates.

Data Hierarchy Code Description

Data Hierarchy

First of all let me describe the non-visual hierarchy that we
want to build.

The WPF’s visual hierarchy is based on the natural containment of visual objects. As was stated above a window might contain a panel – a panel further might contain other panels and controls etc.

The non-visual hierarchy that we deal with is Property Map and the classes
that represent that hierarchy are contained under NP.Paradigms.DataHierarchy project. In a sense it mimics the data hierarchy within JSON code: there are Fields, Property Maps, and Collections.

A Field would only contain a value of type object.

A Property Map corresponds to a C# object –
it has a number of named properties each has a value. The values can be plain Fields, other Property Maps or Collections. The name of a property is unique within the map object. I implemented such maps as a Dictionary with string keys
corresponding to the name of the property and values – the property value. In JSON such object would be shown within curly brackets:


{
name1 : value1,
name2 : value2
}


Collection is a collection of objects (usually of similar structure) that can be either Property Maps or Fields. In JSON collections are denoted by square brackets:


[
value1,
value2
]


Clearly our Data Hierarchy can be used to represent a very wide range of models – in particular anything that can be represented by JSON or C# classes and collections can be represented by the Data Hierarchy.

Classes Describing the Data Hierarchy

As was mentioned above all the classes describing our Data Hierarchy model are locate under NP.Paradigms.DataHierarchy project.

All the Data Hierarchy classes implement IPresentationTreeNode interface. This interface has Parent property that points from the current object to its parent within the Data Hierarchy. IPresentationTreeNode also extends IDataContextContainer interface that defines DataContext property that all the members of the hierarchy should implement. Just like in WPF, the DataContext property contains the data object from which the member of the hierarchy gets its values via binding.

There is also IPresentationTreeNodeWithChildren<T> interface that extends IDataContextContainer and in addition also defines a collection Children.

FieldPresenter class corresponds to a single value Data Hierarchy node. Its property TheValue contains the corresponding value. Its subclass TextFieldPresenter also allows formatting the values for text presentation.

CollectionPresenter defines a collection within Data Hierarchy by its property Children.

PropertyMapPresenter represents the Property Map nodes within Data Hierarchy. It implements IDictionary so that one can use the indexer notations (square brackets) to define the name-value mappings, e.g:
myMap["Name"] = value

Note that classes that implement Data Hierarchy nodes fire PropertyChanged events when their properties change. Also Children property of the CollectionPresenter is implemented as ObservableCollection and correspondingly fired CollectionChanged event when the items are changed within the collection (removed, added or moved). This is necessary so that the bindings that have the Data Hierarchy nodes as source would work.

Classes for XAML Composition using Data Templates

Classes used for XAML composition are also defined under NP.Paradigms.DataHierarchy project.

DHierarchyContentControl and DHierarchyItemsControl correspond to the WPF’s ContentControl and ItemsControl classes.

DHierarchyContentControl defines properties Content and ContentTemplate.
ContentTemplate defines the sub-hierarchy of the node while Content property allows to switch the data context of its sub-nodes.

DHierarchyItemsControl defines properties ItemsSource and ItemTemplate. ItemsSource should be bound to a collection of objects. ItemTemplate specified the structure of each of the sub-nodes within DHierarchyItemsControl‘s Children collection. The resulting Children collection behaves similar to the ItemsSource collection if an item is added or removed from ItemsSource the corresponding item will be added or removed from the Children collection.

There is a number of classes for reading and processing XAML data templates. Class DHierarchyDataTemplate is used for storing the Data Hierarchy data templates within DHierarchyContentControl and DHierarchyItemsControl. DHierarchyTemplateContent together with DHierarchyContentLoader and AvalonXamlReader control loading the data templates from XAML.

Usage Code Description

Here we describe how the Data Hierarchy code with data template capabilities can be used.

The mock up data is contained under MockUpObjects. Here we consider only two classes: Organization and Person. Both are very simple Organization contains its name and a collection of people. Person simply contains first and last name of the person.

The main project in NonVisualDataTemplates. It defines an organization as its resource:

  <MockUps:Organization x:Key="TheWonkaChocolateFactoryOrganization" />

Around the organization object it defines the Data Hierarchy data template. While on top of the Data Hierarchy data template it defines a visual representation (just in order to be able to see that it works).

Data Hierarchy representation is defined by the following templates:

<hierarchy:DHierarchyDataTemplate x:Key="EmployeeNonVisualDataTemplate">
    <hierarchy:PropertyMapPresenter>
        <hierarchy:FieldPresenter x:Key="FirstName" 
                                  TheValue="{winparadigms:Bind SourcePath=FirstName, 
                                                               SourceMode=DataContext}"/>
        <hierarchy:FieldPresenter x:Key="LastName" 
                                  TheValue="{winparadigms:Bind SourcePath=LastName, 
                                                               SourceMode=DataContext}"/>
    </hierarchy:PropertyMapPresenter>
</hierarchy:DHierarchyDataTemplate>

This template define the Data Hierarchy representation of a person (employee)

<hierarchy:DHierarchyDataTemplate x:Key="TheOrganizationTemplate">
    <hierarchy:PropertyMapPresenter>
        <hierarchy:FieldPresenter x:Key="OrgName" 
                                  TheValue="{winparadigms:Bind SourcePath=OrgName, 
                                                               SourceMode=DataContext}"/>
        <hierarchy:DHierarchyItemsControl x:Key="People"
                                          ItemsSource="{winparadigms:Bind SourcePath=People, 
                                                                          SourceMode=DataContext}"
                                          ItemTemplate="{StaticResource EmployeeNonVisualDataTemplate}"/>
    </hierarchy:PropertyMapPresenter>
</hierarchy:DHierarchyDataTemplate>

This template defines the whole organization with multiple employees.

DHierarchyContentControl ‘marries’ the organization template and the organization data:

<hierarchy:DHierarchyContentControl ContentTemplate="{StaticResource TheOrganizationTemplate}"
                                       Content="{StaticResource TheWonkaChocolateFactoryOrganization}"
                                       x:Key="TheDHierarchyContentControl"/>

In order to visualize the results, a plain visual WPF hierarchy is build around the
DHierarchyContentControl:

<Grid Grid.Row="0" 
      DataContext="{winparadigms:Bind Source={StaticResource TheDHierarchyContentControl}}">
    <Grid.RowDefinitions>
        <RowDefinition Height="Auto" />
        <RowDefinition Height="*" />
        <RowDefinition Height="Auto" />
    </Grid.RowDefinitions>

    <TextBlock Text="{winparadigms:Bind SourcePath=Child.-OrgName-.TheValue, SourceMode=DataContext}"
               Margin="10,0,0,0"/>

    <Border Grid.Row="1"
        BorderBrush="Black"
        BorderThickness="2"
        Margin="5">
        <ItemsControl ItemsSource="{winparadigms:Bind SourcePath=Child.-People-.Children, SourceMode=DataContext}">
            <ItemsControl.ItemTemplate>
                <DataTemplate>
                    <Grid>
                        <Grid.ColumnDefinitions>
                            <ColumnDefinition Width="Auto" />
                            <ColumnDefinition Width="Auto" />
                        </Grid.ColumnDefinitions>
                        <TextBlock Text="{winparadigms:Bind SourcePath=Child.-FirstName-.TheValue, SourceMode=DataContext}" />
                        <TextBlock Text="{winparadigms:Bind SourcePath=Child.-LastName-.TheValue, SourceMode=DataContext}" 
                                   Grid.Column="1"
                                   Margin="20,0,0,0"/>
                    </Grid>
                </DataTemplate>
            </ItemsControl.ItemTemplate>
        </ItemsControl>
    </Border>
</Grid>

Note that we are using Bind markup extension instead of Binding. This extension has been described in some of the previous blog entries.

Also note that ‘-‘ character around a path link specifies that this path link is actually a key inside a Dictionary for the Bind markup extension. Also SourceMode=DataContext means
that we are binding to the DataContext property (by default Bind extension binds to
the object on which it is defined, not to its DataContext).

There are two buttons at the bottom of the application that allow to modify the original Organization object. The very simple for modifying the original Organization is located in MainWindow.xaml.cs code behind file. You can add an employee or you can replace its People collection with another collection. These changes will cause changes in Data Hierarchy representation and those in turn will cause the visual representation to change.

After running the application (and pressing a button to add an employee) you’ll see the following picture:

Conclusion

We’ve shown implementing XAML data templates for non-WPF (and even non-Visual) objects.

Code Location

CodeProject

The code for this blog post can be downloaded from
AttachedRoutedEvents.zip.

Introduction

Here I continue a series of blog posts regarding implementing WPF
concepts outside of WPF.

In Attached Properties outside of WPF I introduced
a notion of AProperty – attached property implementation
outside of WPF. Unlike WPF attached property,
such property can be attached to any object –
not only to DependencyObject.

Just like AProperty can be added to an object
without modifying the object’s code, we can come up with the
REvent concept
similar to WPF’s attached event in order add an event to an
object without modifying the object’s code.

In Tree Structures and Navigation we were talking
about navigating a Tree from
node to node. The REvents can also be propagating
from node to node on a tree in a manner similar to that of
WPF’s RoutedEvents propagating on a visual tree.

Attached and Routed Events in WPF

Each event has 4 important actions associated with it:

1. Defining an event
2. Adding handlers to an Event
3. Removing handlers from an Event
4. Raising or Firing an Event from an object

In WPF and Silverlight one can use Attached Events –
events defined outside of an object in which they are being
raised. These Attached Events are
also called Routed Events for the
reason that we are going to explain shortly.

Here is how we define those 4 action above for attached WPF events.

1. Unlike plain C# events, the Attached Events should
   be defined outside of an object in a static class:

   public static RoutedEvent MyEvent=EventManager.RegisterRoutedEvent(...)

   The Routed Event is associated with an object when it is being raised
   from it.

2. In order to add a handler to a Routed Event to an object,
   the following code is employed:

           myObject.AddHandler(MyRoutedEvent, eventHandlerFunction, ...)
         

   The myObject should always be a FrameworkElement in order to be able to
   detect and handle an Routed Event.

3. Removing a Routed Event is done in a similar fashion:

           myObject.RemoveHandler(MyRoutedEvent, eventHandlerFunction)
         

4. We can raise a Routed Event on a FrameworkElement
   object by using its RaiseEvent method:

           myObject.RaiseEvent(routedEventArgs)
         

   routedEventArgs should contain a reference to the
   static Routed Event object defined (registered)
   as MyEvent, above.

These WPF Attached Events are also called Routed Events because they the handler for such event does not have to be defined on the same object on which
the event is raised or not even on an object that has a reference to an object on which such event is raised.
In fact Routed Event can propagate through the anscestor of object that raised such event within the Visual Tree that the object belongs to.

The Routed Events propagating up the Visual Tree (from the raising object to its anscestors) are called Bubbling events.
The Routed Events can also visit the anscestors first, starting from the
root node of the Visual Tree and ending the propagation at the
node that raised the Routed Event. Such events are called Tunneling events. Routed Events can also be neither
Bubbling nor Tunneling – in that case
they can only be handled on the object that raised them. Such events are called Direct event.

The routing behavior of an event (whether it is Bubbling, Tunneling or Direct is determined at the stage when the event is defined (registerd).

What we are Trying to Achieve

Here we are implementing Routed Event WPF concept outside of WPF.
Such event can Bubble and Tunnel and
also can propagate to Tree Node‘s descendants on any
Tree defined by its up and down propagation functions,
not only the Visual Tree. Such events can also be attached to any
objects, not only to FrameworkElements. The routing behavior of such an event is determined at the
time when it is raised, not at the time when it is defined. The event can have up to 4 arguments
specified by generic types.

Usage Example

We are going to show how the API is being used first, and only after that describe the implementation.

The test code is located within Program.cs file under AttachedRoutedEventTest project. We build the Tree in exactly the same fashion as it was done in Tree Structures and Navigation:

#region Start building tree out of TestTreeNodes objects
TestTreeNode topNode = new TestTreeNode { NodeInfo = "TopNode" };

TestTreeNode level2Node1 = topNode.AddChild("Level2Node_1");
TestTreeNode level2Node2 = topNode.AddChild("Level2Node_2");

TestTreeNode level3Node1 = level2Node1.AddChild("Level3Node_1");
TestTreeNode level3Node2 = level2Node1.AddChild("Level3Node_2");

TestTreeNode level3Node3 = level2Node2.AddChild("Level3Node_3");
TestTreeNode level3Node4 = level2Node2.AddChild("Level3Node_4");
#endregion End tree building
  

Here is how we define the toParentFunction and toChildrenFunction for the tree:

// to parent function
Func toParentFn =
    (treeNode) => treeNode.Parent;

// to children function
Func<TestTreeNode, IEnumerable> toChildrenFn =
    (treeNode) => treeNode.Children; 

First we print all the nodes of the tree shifted to the right in proportion to their distance from the top node:

IEnumerable<TreeChildInfo<TestTreeNode>> allTreeNodes =
    topNode.SelfAndDescendantsWithLevelInfo(toChildrenTreeFunction);

// print all the tree nodes
Console.WriteLine("\nPrint all nodes");
foreach (TreeChildInfo<TestTreeNode> treeNode in allTreeNodes)
{
    string shiftToRight = new string('\t', treeNode.Level + 1);
    Console.WriteLine(shiftToRight + treeNode.TheNode.NodeInfo);
}
  

Here is the result of printing:

TopNode
    Level2Node_1
        Level3Node_1
        Level3Node_2
    Level2Node_2
        Level3Node_3
        Level3Node_4

Here is how we create REvent:

REvent<TestTreeNode, string> aTestEvent = new REvent();  

By the type arguments we specify that this REvent will act on objects
of the type TestTreeNode and will be accepting objects of type
string as arguments – overall we can specify from 0 to 4 arguments
of different types for the REvent objects.

Now we can set our REvent‘s handlers for all the nodes of the tree:

// assign handlers for each of the 
foreach (TreeChildInfo<TestTreeNode> treeNodeWithLevelInfo in allTreeNodes)
{
    TestTreeNode currentNode = treeNodeWithLevelInfo.TheNode;

    aTestEvent.AddHander
    (
        currentNode,
        (str) =>
        {
            Console.WriteLine("Target Node: " + currentNode.NodeInfo + "\t\t\tSource Node: " + str);
        }
    );
}  

The handler would print the current node’s name and the string passed to the handler as
the source node’s name (it is assumed that the RaiseEvent function has the
name of the raising tree node passed as an argument).

Now we raise different events (bubbling, tunneling, direct and propagating to children) and observe the results

Bubbling Event

Console.WriteLine("\nTesting event bubbling:");
aTestEvent.RaiseBubbleEvent(level3Node3, toParentTreeFunction, level3Node3.NodeInfo);    
  

Bubbling event raised from the bottom level node level3Node3 will print the node itself and
all its ancestors printing first those who are closer to the originating node level3Node3:

Testing event bubbling:
Target Node: Level3Node_3			Source Node: Level3Node_3
Target Node: Level2Node_2			Source Node: Level3Node_3
Target Node: TopNode			        Source Node: Level3Node_3    
  

Tunneling Event

Console.WriteLine("\nTesting event tunneling:");
aTestEvent.RaiseTunnelEvent(level3Node3, toParentTreeFunction, level3Node3.NodeInfo);

Tunneling event will print the same nodes in the opposite order – starting from the top node and
ending with the originating node:

Testing event tunneling:
Target Node: TopNode			        Source Node: Level3Node_3
Target Node: Level2Node_2			Source Node: Level3Node_3
Target Node: Level3Node_3			Source Node: Level3Node_3  

Direct Event

Console.WriteLine("\nTesting event Direct Event (without bubbling and tunneling):");
aTestEvent.RaiseEvent(level3Node3, level3Node3.NodeInfo);  

Direct event will only print on the invoking node:

Testing event Direct Event (without bubbling and tunneling):
Target Node: Level3Node_3			Source Node: Level3Node_3  

Event Propagating to Descendents

Console.WriteLine("\nTesting event propagation to descendents:");
aTestEvent.RaiseEventPropagateToDescendents(level2Node1, toChildrenTreeFunction, level2Node1.NodeInfo);  

Event propagating to descendents fired from level2Node1 node located at the middle level,
will print the node itself and its two descendents:

Testing event propagation to descendents:
Target Node: Level2Node_1			Source Node: Level2Node_1
Target Node: Level3Node_1			Source Node: Level2Node_1
Target Node: Level3Node_2			Source Node: Level2Node_1 

Terminating Event Propagation

One can pass a Func instead of na Action to become an event
handler for the REvent. In that case, returning false from that function
would terminate the REvent propagation – analogous to setting e.Cancel=true
for WPF’s routed event.

Below we clear the event handler at level2Node2 node and reset to to
a Func that always returns false:

// stopping propagation by returning false from a handler
aTestEvent.RemoveAllHandlers(level2Node2);

aTestEvent.AddHander
(
    level2Node2, 
    () => 
    {
        Console.WriteLine("Terminating event propagation at node " + level2Node2.NodeInfo); 
        return false;
    }); // terminate event propagation at this node

After this we re-run the bubbling, tunneling and propagating to children events:

Console.WriteLine("\nTesting event bubbling with event propagation termination:");
aTestEvent.RaiseBubbleEvent(level3Node3, toParentTreeFunction, level3Node3.NodeInfo);


Console.WriteLine("\nTesting event tunneling with event propagation termination:");
aTestEvent.RaiseTunnelEvent(level3Node3, toParentTreeFunction, level3Node3.NodeInfo);


Console.WriteLine("\nTesting event propagation to descendents with event propagation termination:");
aTestEvent.RaiseEventPropagateToDescendents(topNode, toChildrenTreeFunction, topNode.NodeInfo);    
  

The results of these are shown below:

Testing event bubbling with event propagation termination:
Target Node: Level3Node_3			Source Node: Level3Node_3
Terminating event propagation at node Level2Node_2

Testing event tunneling with event propagation termination:
Target Node: TopNode			Source Node: Level3Node_3
Terminating event propagation at node Level2Node_2

Testing event propagation from the TopNode to its descendents with event propagation termination:
Target Node: TopNode			    Source Node: TopNode
Target Node: Level2Node_1			Source Node: TopNode
Target Node: Level3Node_1			Source Node: TopNode
Target Node: Level3Node_2			Source Node: TopNode
Terminating event propagation at node Level2Node_2 

You can see that the event propagation stops indeed at level2Node2 node.

Notes on Implementation

NP.Paradigms.REvent implementation code is located within REvent.cs file
under NP.Paradigms project.

REvent class defines AProperty _aProperty. Its purpose is to provide
a mapping between the objects on which some REvent handlers were set and objects of type
REventWrapper that actually saves the REvent handlers.

REventWrapper has _event member of List<Func<T1,T2,T3,T4,bool>>
type. It accumulates all of the event handlers associated with its object. It also has a bunch of functions
that help to convert Actions and Funcs with smaller amount of generic
type arguments into Func<T1,T2,T3,T4, bool>. There is also a map:
Dictionary<object, Func> _delegateToFuncMap that stores the mapping between
the original Action or Func with smaller number of generic type arguments and
the final Func<T1,T2,T3,T4>. This is needed if we want to remove a handler – we’ll need to find
the correct Func<T1,T2,T3,T4> and remove if from the _event list.

REvent class has various functions for adding the event handlers to an object. It also has functions
for raising event on an object so that it would propagate in a required fashion: bubbling, tunneling, direct or
propagation to children – as they were presented in the usage example section.

CodeProject

I continue a series of blog posts about implementing WPF
concepts outside of WPF.

Even though, the purpose of these articles is to show how to implement
and use WPF concepts outside of WPF, WPF and XAML application are still the major beneficiaries of
this new approach which will allow to e.g. create bindings between properties on the non-visual View Models
or extend the non-visual View Models (by using AProperties) without modifying the View Model code.
Because of this, it makes sense to create a XAML markup extension for the non-WFP binding
described in Composite Path Bindings outside of WPF. This article talks about creating and using such markup extension.

The source code for this blog post is located under
BindMarkupExtensionCode.zip link.

Bind Extension

To distinguish the new markup extension from WPF’s Binding markup extension, we’ll call it Bind
or BindExtension.

BindExtension class is located under NP.Paradigms.Windows project. It extends
System.Windows.Markup.MarkupExtension class. It has the following public properties that can be
set in XAML:

1. Source – allows to specify the binding source object. If Source property is not
   specified, we are trying to figure out the source object from other properties e.g.
   SourceElementName described below. If nothing helps, the source object is assumed to be the same
   as the target object (we still have no notion similar to the DataContext in WPF bindings).
2. SourceElementName – is similar to ElementName of WPF binding. It allows to specify a
   named XAML element to serve as the Binding‘s source.
3. SourcePath – a string that specifies the path of the binding relative to the binding’s
   Source object.
   The path links are separated by periods (‘.’). The plain properties are specified as strings. The WPF attached
   or dependency properties are placed within parentheses. The AProperties are placed within two
   asterisks. Here is a composite path sample: MyPlainProp.(this:MyAttachedProps.MyTestAttachedProp).*this:MyTestAProps.MyTestAProp*. This path is looks for AProperty MyTestAProps.MyTestAProp within
   an object defined by an attached property MyAttachedProps.MyTestAttachedProp within an object
   define by a plain property MyPlainProp of the source object of the binding. Both attached property
   and AProperty are defined within the current project specified by XAML prefix “this:”.
4. TargetPath – a string that specifies the path to the target of the binding
   with respect to the target binding object and the target property. Unlike the WPF binding
   our composite path binding allows to specify a composite target path (see Composite Path Bindings outside of WPF). The first link or the
   target path will always be the target property defined within XAML. The subsequent links can be
   defined by TargetPath string. Here is a XAML example
   <Grid DataContext={Bind TargetPath="MyProp"...}. This example will not set the
   DataContext property on the grid. Instead it will use DataContext property as the first link
   in the target binding and will modify DataContext.MyProp property instead (if it exists, of course).
   If TargetPath is not specified, the XAML target property will be modified.
5. TheBindType – similar to WPF binding’s Mode. Here are the possible values
   • OneWay – binding from source to target property
   • OneWayReverse – binding from target to source property (similar to WPF’s OneWayToSource)
   • TwoWay – binds source and target properties together so that when one of them changes, the other changes also. The initial value is set from source to target.
   • TwoWayReverseInit – binds source and target properties together so that when one of them changes, the other changes also. The initial value is set from target to source.

Usage Samples

Project XamlBindingTests shows how to use the BindExtension in XAML. The relevant XAML code is located within
MainWindow.xaml file. Here is how the test application looks:

Test1 demonstrates attaching plain property to dependency property using Bind extension.
Text property of a TextBlock is bound to MyTestProp property
of a resource object MyTestDataObj_Test1:

<TextBlock Text="{winparadigms:Bind Source={StaticResource MyTestDataObj_Test1},
                                    SourcePath=MyTestProp}"
           Grid.Column="1"/>

When a button “Add Value to Plain Prop” is clicked the property of the resource object is added “_hi” at the end and the binding
transfers the corresponding change to the Text property of the TextBlock object.

Test2 shows how to set the binding in both directions – from a Text property on
TextBox to a resource object and
from the resource object to the Text property on a TextBlock:

<TextBox Width="100"
          Height="25"
          Text="{winparadigms:Bind Source={StaticResource MyTestDataObj_Test2},
                                 SourcePath=MyTestProp,
                                 TheBindType=OneWayReverse}"/>

<TextBlock Text="{winparadigms:Bind Source={StaticResource MyTestDataObj_Test2},
                                    SourcePath=MyTestProp}"
           Grid.Column="1" />

When you start typing
in the TextBox the TextBlock text shows next to it.

Test3 demos a two TwoWay bindings – one from a TextBox to a resource object and
the other from the same resource object back to a different text box.
The two text boxes are thus bound in both directions via a resource object:

<TextBox Width="100"
            Height="25"
            Text="{winparadigms:Bind Source={StaticResource MyTestDataObj_Test3},
                                    SourcePath=MyTestProp,
                                    TheBindType=TwoWayReverseInit}" />

<TextBox Width="100"
          Height="25"
          Text="{winparadigms:Bind Source={StaticResource MyTestDataObj_Test3},
                                 SourcePath=MyTestProp,
                                 TheBindType=TwoWay}"
          Grid.Column="1" />

Test4 shows how to use SourceElementName to bind Text properties in
two TextBox objects:

<TextBox Width="100"
            Height="25"
            Text="{winparadigms:Bind SourceElementName=TextBoxToMatch,
                                    SourcePath=(TextBox.Text),
                                    TheBindType=TwoWay}" />
<TextBox Width="100"
          Height="25"
          x:Name="TextBoxToMatch"
          Text="Text to match"
          Grid.Column="1" />

Finally Test5 shows how to bind an AProperty. The AProperty
this:MyAProps.MyTestAProp is defined on the
resource object MyTestDataObj_Test5. It is bound to its own plain property MyTestProp:

<this:MyTestData x:Key="MyTestDataObj_Test5"
                  this:MyAProps.MyTestAProp="{winparadigms:Bind SourcePath=MyTestProp, TheBindType=TwoWay}"
                  MyTestProp="InitialValue" />

Also one TextBox of Test5 binds its Text to the plain MyTestProp
of the resource object MyTestDataObj_Test5, while the other TextBox of the test
binds to the AProperty:

<TextBox Width="100"
         Height="25"
         Text="{winparadigms:Bind Source={StaticResource MyTestDataObj_Test5},
                                  SourcePath=MyTestProp,
                                  TheBindType=TwoWay}" />
<TextBox Width="100"
         Height="25"
         Text="{winparadigms:Bind Source={StaticResource MyTestDataObj_Test5},
                                  SourcePath=*this:MyAProps.MyTestAProp*,
                                  TheBindType=TwoWay}"
         Grid.Column="2" />

Thus the two TextBoxes are bound together via a plain property and an AProperty on a resource object.