Stefan Wick's Weblog - Development with Silverlight, WPF and Tablet PC : Tablet

Back-of-pen Erasing in Silverlight

swick — Tue, 02 Dec 2008 00:25:00 GMT

As addendum to my previous post Erasing Ink in Silverlight 2 I want to show how to enable back-of-pen erasing for users with a compatible stylus device (e.g. on a Tablet PC or with an external Graphics Tablet).

The key that enables this scenario is the StylusDevice.Inverted property. It reports during mouse events whether the front-of-pen (stylus) or back-of-pen (eraser) is being used. The app can then switch into inking or erasing mode automatically, according to this value.

Here is the code-behind you need to add for an InkPresenter to enable this scenario:

public partial class Page : UserControl

{

public Page()

{

InitializeComponent();

}

private void inkPresenter_MouseLeftButtonDown(object sender,
MouseButtonEventArgs e)

{

inkPresenter.CaptureMouse();

if (e.StylusDevice.Inverted == false)

{

// ink mode

newStroke =

new Stroke(e.StylusDevice.GetStylusPoints(inkPresenter));

inkPresenter.Strokes.Add(newStroke);

}

else

{

// erase mode

erasePoints = e.StylusDevice.GetStylusPoints(inkPresenter);

}

private void inkPresenter_MouseMove(object sender, MouseEventArgs e)

{

if (e.StylusDevice.Inverted == false)

{

// ink mode

if (newStroke != null)

{

newStroke.StylusPoints.Add(

e.StylusDevice.GetStylusPoints(inkPresenter));

}

else if (e.StylusDevice.Inverted == true)

{

// erase mode

if (erasePoints != null)

{

erasePoints.Add(
e.StylusDevice.GetStylusPoints(inkPresenter));

StrokeCollection hitStrokes =
inkPresenter.Strokes.HitTest(erasePoints);

foreach (Stroke hitStroke in hitStrokes)

{

inkPresenter.Strokes.Remove(hitStroke);

}

private void inkPresenter_MouseLeftButtonUp(object sender,
MouseButtonEventArgs e)

{

inkPresenter.ReleaseMouseCapture();

erasePoints = null;

newStroke = null;

}

private StylusPointCollection erasePoints = null;

private Stroke newStroke = null;

}

Snipping Pictures with Silverlight

swick — Tue, 18 Dec 2007 20:45:00 GMT

One of my favorite tools on the Tablet PC is the 'Snipping Tool'. I have been using it frequently since the early XP days (back then we shipped it seperately as a Power Toy). Now in Vista, it's part of the main OS and I find myself using it quite often event on my desktop PC.

When I was using the tool recently, I got this idea for a new Silverlight sample app: wouldn't it be cool to snip pieces from various images and put them together as a collage in Silverlight - and then annotate the result with text, drawings and/or handwriting?

Silverlight's imaging and ink APIs make this fairly easy. Here are my results of this effort using Silverlight v1.0 - the sample demonstrates these features:

Select an image from an animated collection of pictures
Snip a piece of the selected image (free-form, rectangle or entire picture) and arrange it on the canvas
Use 'Image Tools' to control zoom, rotation and opacity of individual snippets
Use 'Text Tools' to add/change text annotations
Use 'Ink Tools' to add/change drawings and handwritten annotations
Full screen and embedded mode

Couple of notes and caveats:

The pictures are currently hardcoded (appropriate for the holiday season :-) ), but you can easily change that in the attached source code to use your own pictures or to pull images from the web.
When you launch the app from this blog, it opens up in full screen mode (since this is the best mode to view and use it). You can press the 'Esc' key or use the 'Miscellaneous' menu to go back to embedded mode.
In full screen mode Silverlight disables keyboard input (for security reasons). So if you want to enter some text annotations, please switch to embedded mode.
The 'Create Bitmap' button doesn't do anything in this version. The idea is to invoke some server-side code here to generate a bitmap of your collage. If there is interest in the community, this might be a good topic for a seperate blog post. But then again: if you are on Windows Vista, you can just use the Snipping Tool in the OS, to grab your collage and save it as bitmap :-)

The sample's complete source code is attached to this post. A live version, hosted via Silverlight Streaming, is included below for you try out. Click the button to launch the app:

TabletPC Development Gotchas Part 5: Rendering ink and image to a bitmap using Winforms

swick — Sun, 02 Dec 2007 08:19:00 GMT

Annotating pictures with handwriting or drawings is a fun and useful scenario for digital ink. In many cases the application user wants to create a new image file with the ink annotation "burnt" into the picture, so they can use the result of their work in other contexts and with other applications (e.g. attach the annotated image to an e-mail or upload it to their personal web site or blog, like the image below).

So rendering ink on top of an image is a common scenario for TabletPC/Ink developers - and it should be real easy, right? Well, there is an important 'gotcha' you need to know about if you want to do this from Winforms. But let's start with native code first.

Using the COM Ink API in native code

If you are using the ActiveX version of InkPicture (or the COM InkOverlay component) then rendering its ink to a GDI bitmap is easy. Just get the hDC (handle to device context) of the bitmap and use the InkRenderer.Draw() method:

pInkRenderer->Draw(hDCtargetBitmap, pStrokesToRender);

Using the Winforms Ink API to target XP (Microsoft.Ink v1.7)

In managed Winforms code, the object that corresponds to the hDC is the System.Drawing.Graphics object. So the intuitive approach would be to get the Graphics object of the Winforms target bitmap and then use the Microsoft.Ink.Render.Draw() method to render the desired ink strokes on top of it. Something along the lines of this:

Graphics graphicsTarget = Graphics.FromImage(imageToSave);

inkPicture1.Renderer.Draw(graphicsTarget,

                            inkPicture1.Ink.Strokes);

imageToSave.Save(“InkAndImage.bmp”);

Unfortunately, the result of this operation does not look great: the quality of the ink on the bitmap is not the same as what you see on the screen. Especially if you set some advanced DrawingAttributes (like Transparency or RasterOperations) the resulting bitmap does resemble the image on the screen very well. What is the reason for this behavior? The short version is that the underlying Ink Renderer and the managed Winforms images use GDI in slightly different ways, so the rendering operation has to fall back to a lower quality mode.

Fortunately, there is a workaround: we can take both the Winforms image and our ink strokes and render them to a temporary device-independent-bitmap. Then we'll render the result of that to the actual target bitmap. In order to do this, however, we have to do some manged<->native code interop magic. All that magic is encapsulated in the DibGraphicsBuffer class (see highlighted line below). This helper class is included in the attached sample project. Here is the relevant code to apply the workaround using that helper class:

Graphics graphicsTarget = Graphics.FromImage(imageToSave);

Graphics graphicsSrc = inkPicture1.CreateGraphics();

DibGraphicsBuffer buffer = new DibGraphicsBuffer();

Graphics graphicsTemp = buffer.RequestBuffer(graphicsSrc,

                                               inkPicture1.Image.Width,

                                               inkPicture1.Image.Height);

graphicsTemp.DrawImage(inkPicture1.Image, new Point(0, 0));

inkPicture1.Renderer.Draw(graphicsTemp, inkPicture1.Ink.Strokes);

buffer.PaintBuffer(graphicsTarget, 0, 0);

Using the Winforms Ink API to target Vista (Microsoft.Ink v6.0)

In order to address the limitation of the XP API, the Vista version of Render.Draw() now has an additional overload that makes the above workaround obsolete (of course the workaround still works on Vista). You can now pass in a Bitmap object directly to the API, and your ink gets rendered onto the image in the highest quality with a one-liner:

inkPicture1.Renderer.Draw((Bitmap)imageToSave, inkPicture1.Ink.Strokes);

Attached Code projects:

I have attached two complete code projects to illustrate how to get the best results on both XP and Vista:

1) RenderInkOnBitmapXP - utilizes the DibGraphicsBuffer class to apply the workaround for Windows XP

2) RenderInkOnBitmapVista - uses the new overload to demonstrate the best practice on Windows Vista

Slide decks from my Oredev sessions

swick — Thu, 15 Nov 2007 16:43:00 GMT

Thanks to everyone who attended my sessions at the Oredev conference in Malmo, Sweden. Thank you also for all the great questions and feedback after the sessions - much appreciated! I have attached my slide decks to this post for those who are interested.

Some of the demos that I coded or showed during the sessions are already on this blog. I am working on getting the missing ones up here as well. Stay tuned ...

Also the video recordings from all Oredev sessions should become available soon on http://www.oredev.org.

Off to Oredev

swick — Mon, 12 Nov 2007 18:45:00 GMT

Just a quick note: I am on my way to Oredev conference. I'll be presenting the following two talks there:

Introduction to application development with WPF and Silverlight for TabletPCs and UMPCs

Advanced application development with WPF and Silverlight for TabletPCs and UMPCs

I'll post slide decks and demos here after I those presentations.

TabletPC Development Gotchas Part4: Semantics of GetSystemMetrics(SM_TABLETPC)

swick — Sun, 04 Nov 2007 21:44:00 GMT

If your application needs to find out at runtime whether or not it runs on a Tablet PC, it is recommended to call GetSystemMetrics() and pass in the value 'SM_TABLETPC'.

But what does it actually mean for a computer to be a Tablet PC? Is that determined by the installed hardware components? Or the software components? All of the above? Some of the above?

Those are almost philisophical questions and I won't try to give a complete answer here. But instead I want to shed some light on the semantics of the actual implementation of GetSystemMetrics(SM_TABLETPC). So if you decide to use that API call in your app after reading this post, you know exactly what you are getting.

XP vs. Vista - Semantic Differences

On Windows XP, the return value GetSystemMetrics(SM_TABLETPC) is exclusively based on software considerations. It returns whether or not your computer is running Windows XP Tablet PC Edition. Back in the day, that made a lot of sense, because this edition was exclusively available to OEMs, and they could only install it on computers that satisfied strict hardware requirements. So checking for the OS type implied certain hardware capabilities. It caused a little bit of confusion for MSDN subscribers who installed the Tablet Edition on their desktops for development purposes. Moreover, the hardware requirements changed overtime (to allow new form-factors, such as UMPCs). Thus, on Windows XP, you cannot really rely on GSM(SM_TABLETPC) to tell you about hardware capabilities, it only tells you reliably what OS edition the user is running on.

On Windows Vista the return value of GetSystemMetrics(SM_TABLETPC) is determined based on several things. It returns true if all of the following conditions are true:

1) There is an integrated digitizer, either pen or touch, on the system.

2) The computer is running a Premium SKU of Windows Vista (Home Premium and above). Those SKUs include a license for the TabletPC optional components (which are also installed by default on those SKUs).

3) Tablet PC Input Service is running. Tablet PC Input Service is a new service for Windows Vista that controls Tablet PC input.

This obviously provides greater accuracy than the XP implementation. However, it also can potentially cause some confusion as all three conditions may change at runtime on a given piece of hardware. For example, you can stop the input service. Now when you launch an app that checks GSM(SM_TABLETPC) to enable/disable some features (like Microsoft Word does), you will notice that some of the inking tools are not available. So at times the same computer might be considered a Tablet PC, and sometimes it is not. Hmmm…

Detecting the presence of specific components:

In most cases checking the presence of the required components is more appropriate than using GSM(SM_TABLETPC). For example if your application relies on the Chinese handwriting recognizer, then calling GSM will be useless, because the recognizer could be present on non-Tablet systems - and it could be missing on a Tablet system. The right thing here is to inspect the Recognizers collection to see if it includes a Chinese handwriting recognizer.

There are two articels on MSDN that contain more information about this approach:

Tablet PC Platform Independence (by Dr. Neil Roodyn)

Microsoft Sudoku: Optimizing UMPC Applications for Touch and Ink (by Stephen Toub; scroll down to the 'Platform Detection' section)

TIP: If by any chance you want your Vista Premium desktop computer to be considered a Tablet PC without doing any hardware upgrades, all you need to do is install a virtual driver that reports itself as integrated stylus digitizer. This will cause GSM(SM_TABLETPC) to return true and as a result, light up all Tablet-specific features on your computer. Check the websites of popular external Tablet manufacturers for the availability of those drivers.

Previous post in this series: TabletPC Development Gotchas Part3: Coerce to Factoid (XP vs. Vista)

Fun with Ink & XAML Part3: Ink Data Binding

swick — Sat, 03 Nov 2007 16:18:00 GMT

Data binding in WPF provides a great way for applications to present and interact with data. Elements can be bound to data from a variety of data sources - for example XML files. I have put together a sample that uses data binding to retrieve a collection of handwritten ink documents from a data store (XML file), present it to the user and let the user interact with it. As always in this series, the task is accomplished by markup only - no code behind required. The sample markup (and the data file) is attached to this post.

Let's take a look at the sample markup, specifically what's inside the <Grid.Resources> tag. I have highlighted the sections that are relevant for the data binding:

<Grid.Resources>

<TextBlock HorizontalAlignment="Center" Foreground="Red"

Text="{Binding XPath=@FileName}"/>

<InkPresenter HorizontalAlignment="Center"

LayoutTransform="0.2,0,0,0.2,0,0">

<InkPresenter.Strokes>

</InkPresenter.Strokes>

</InkPresenter>

</StackPanel>

</DataTemplate>

</Grid.Resources>

The first item here is the XmlDataProvider. This class facilitates the access to XML data for data binding. The other item, our DataTemplate, defines how the data is being presented: The 'FileName' value gets assigned to a <TextBlock/> and the 'Strokes' value gets assigned to the Strokes property of an <InkPresenter/>.

To see how these two resources are being used in the actual UI markup, let's inspect the ListBox element. The ListBox is being used to display a thumbnail view of all ink documents in the data store and to let the user choose which document they want to view or edit.

<ListBox Name="lbStrokes" Background="AntiqueWhite"

ItemsSource="{Binding Source={StaticResource InkData},

XPath=InkFile}"

ItemTemplate="{StaticResource InkDataTemplate}"/>

Now to view and interact with the selected item from our ListBox, we are adding a larger InkCanvas element that is data-bound to the ListBox. So when the user selects a new ink note from the list, that document gets loaded into the InkCanvas automatically. Here is the relevant markup to set up that binding:

<InkCanvas DataContext="{Binding ElementName=lbStrokes,Path=SelectedItem}"

Strokes="{Binding XPath=@Strokes}"

Background="Snow">

Below is a screenshot of the sample that is attached to this post. To run it, unpack the .zip file and load the .xaml file into XamlPad - or just double-click it to open it in IE. Note that the data file (InkData.xml) must reside in the same location as the XAML file.

Next post in this series: Fun with Ink & XAML Part4: WPF BitmapEffects applied to Ink

Previous post in this series: Fun with Ink & Xaml - Part2: Zoom and Scroll

TabletPC Development Gotchas Part3: Coerce to Factoid (XP vs. Vista)

swick — Sat, 03 Nov 2007 15:50:00 GMT

If you are writing (or maintaining) and application that uses handwriting recognition, please be aware of a subtle behavior difference between XP and Vista when coercing the recognition result to a Factoid (or an input scope or a word list). This may easily be missed in your application testing, but it will potentially result in unhandled exceptions from your application when consumers are starting to use it.

Here is the scoop: normally, when you assign strokes to a RecognizerContext for recognition, it will always be able to return some result - even for random scribbling. However, if you set the 'Coerce' flag to bias the recognizer towards a certain format (e.g. Date, URL, etc.) or word list (e.g. medical terms) then there is a (small) chance that it will not be able to compute a result. On Windows XP, the RecognizerContext returns a null RecognitionResult in this case. On Windows Vista, however, an InvalidOperationException is thrown.

So if you have written an application agains the XP behavior, please update your code to also catch InvalidOperationException if you expect your customers to use your app on Windows Vista. If you are writing a new app today on Vista, please be sure to also check the RecognitionResult for null if you plan to support your product on Windows XP Tablet PCs.

To clarify the issue in code, consider the following example: the goal here is to recognize a given strokes collection as URL. Now if the strokes are random enough, the recognizer won't be able to coerce it to a valid URL (with my handwriting, for example, writing "ooooo" does not yield a result).

private string Recognize(Strokes strokesToRecognize)

{

RecognitionStatus status;

RecognizerContext recoContext = new RecognizerContext();

recoContext.Factoid = "(!IS_URL)";

recoContext.RecognitionFlags = RecognitionModes.Coerce;

recoContext.Strokes = strokesToRecognize;

try

{

RecognitionResult result = recoContext.Recognize(out status);

if (result != null)

{

return result.TopString;

}

else

{

// Windows XP code path

return "Null means NO RESULT on XP";

}

catch (InvalidOperationException)

{

// Windows Vista code path

return "InvalidOperationException means NO RESULT on Vista";

}

So the bottom line is: if you are writing an application that uses handwriting recognition, you should harden your code to handle both a 'null' result as well as an 'InvalidOperationException' from calling RecognizerContext.Recognize().

Next post in this series: TabletPC Development Gotchas Part4: Semantics of GetSystemMetrics(SM_TABLETPC)

Previous post in this series: TabletPC Development Gotchas Part2: Deploying InkPicture applications to Windows XP desktops

TabletPC Development Gotchas Part2: Deploying InkPicture applications to Windows XP desktops

swick — Fri, 02 Nov 2007 02:02:00 GMT

If you are developing applications that use an InkPicture control and you plan to deploy your product to customers running Windows XP desktop OS (i.e. not the Windows XP Tablet PC Edition), please read on:

The TabletPC controls (InkPicture and InkEdit) have been designed for being used on Windows XP TabletPC Edition. On other pre-Vista operating systems (Windows 2000, Windows 2003 and non-Tablet PC editions of Windows XP) you can instantiate these controls but can't use them for ink input. This is documented on MSDN.

So far so good. Now, the confusing part is that ink input in those controls is actually enabled on desktop computers for 'development and testing purposes'. The control determines whether you are 'developing and testing' by checking for the presence of the Tablet PC SDK on the machine at runtime. So, if you didn't read the fine print on MSDN and you do all your testing on development machines that happen to have the Tablet PC SDK installed, you will not notice this limitation until a consumer actually installs the application on a desktop computer without SDK.

Fortunately, this limitation has been removed in Windows Vista. The InkPicture control will collect ink on all Windows Vista SKUs and hardware configurations. Moreover, there also is a solution for deploying to Windows XP desktops. The following two facts are key here:

1) the downlevel deployment limitation does not apply to the InkOverlay component

2) attaching an InkOverlay to a PictureBox controls provides feature parity to InkPicture

So you can go ahead and build your own InkPicture control by extending the PictureBox control with an InkOverlay. Now it is deployable to non-Tablet PC, pre-Vista operating systems. Be sure to expose the InkOverlay methods, properties and events to the consumer of your control. My simple example below does this by making the entire InkOverlay a public property. You can do it more elegantly by exposing each relevant method, property and event individually on the control level - and then basically call through to the inner InkOverlay component.

class MyInkPicture : PictureBox

{

private InkOverlay _inkOverlay;

public MyInkPicture()

{

_inkOverlay = new InkOverlay(this);

_inkOverlay.Enabled = true;

}

public InkOverlay InkOverlay

{

get { return _inkOverlay; }

}

Next post in this series: TabletPC Development Gotchas Part3: Coerce to Factoid (XP vs. Vista)

Previous post in this series: TabletPC Development Gotchas Part1: Handling exceptions in Winforms Ink events

Shape Recognition with WPF and InkAnalysis

swick — Thu, 01 Nov 2007 19:45:00 GMT

Did you know that the Windows Vista SDK contains a shape recognition engine? It's part of the InkAnalysis framework that provides APIs for handwriting recognition, ink parsing and shape recognition. This framework enables some really cool scenarios, especially when combined with WPF. And it's very easy to program against it from a WPF app due to its strongly-typed, WPF-friendly wrapper assembly (iawinfx.dll). Today I want to focus on shapes, I'll work on a seperate post for handwriting recognition (for an overview of InkAnalysis take a look at this MSDN topic).

The sample that comes with this post in the attachment lets the user draw a shape (triangle, ellipse, rectangle, polygon) using the mouse (or stylus if available). The shape reco engine then kicks in and returns the corresponding WPF shape element. Once the shape elements are in the WPF tree, you can use the CheckBoxes to animate or move them around.

One of the key lines in the code is where we tell the InkAnalyzer that our ink stroke should be considered as 'Drawing' (as opposed to handwriting).

inkAnalyzer.SetStrokesType(e.Added, StrokeType.Drawing);

Then, when we get the result nodes from the InkAnalyzer, it will return the actual WPF shape objects, like this:

InkDrawingNode drawingNode = resultNode as InkDrawingNode;

if (drawingNode != null && drawingNode.GetShapeName() != "Other")

{

Shape shapeToAdd = drawingNode.GetShape();

...

}

Here is a screenshot of the sample just before completing the ink stroke:

After MouseUp (or StylusUp), shape recognition kicks in and the WPF shape element gets added to the Canvas.

Now that your handwritten stroke has been converted to a WPF shape, you can utilize the full power of WPF and do fancy things with them. For example: render them with semi-transparent gradients, animate smoothly or move them around - as demonstrated in my sample. The full sample project is attached to this post.

TabletPC Development Gotchas Part1: Handling exceptions in Winforms Ink events

swick — Thu, 01 Nov 2007 17:05:00 GMT

Over the past few years of developing apps using the TabletPC platform, I came across a couple of gotchas that are not exactly obvious to solve or workaround (at least they were not obvious to me). I figured I should blog about those and the respective solutions or workarounds to save others some head-scratching.

Here is the first one - it applies to the Microsoft.Ink assembly for developing inking apps using Winforms. Consider the following trivial app:

using System;

using System.Drawing;

using System.Windows.Forms;

using Microsoft.Ink;

class Program : Form

{

private InkOverlay _inkOverlay;

public Program()

{

_inkOverlay = new InkOverlay(this);

_inkOverlay.Enabled = true;

_inkOverlay.Stroke += new InkCollectorStrokeEventHandler(_inkOverlay_Stroke);

}

void _inkOverlay_Stroke(object sender, InkCollectorStrokeEventArgs e)

{

int foo = 2;

int bar = 5 / (2 - foo);

e.Stroke.DrawingAttributes.Color = Color.Red;

this.Invalidate();

}

static void Main(string[] args)

{

Application.Run(new Program());

}

The goal of the app is that each new stroke turns red once the stroke has been completed. However, when you run the app, this doesn't actually happen. The app works, but the ink remains in the default color (black). If you set a breakpoint on the line that sets the stroke's color to red, the breakpoint never gets hit. If you set a breakpoint at the top of the Stroke handler and step through the code, you will notice that the code execution returns to the app just before the color would be set.

Why is that? Well, in this simple example it's easy to see that there is a bug (division by zero). But why isn't the exception reported to us as an unhandled exception? The answer is not that obvious. It is due to the fact that the Microsoft.Ink assembly is really just a managed wrapper around a COM library (InkObj.dll). Take a look at the callstack when the event handler gets hit and you will see that your handler is being called from native code. So the unhandled, managed DivideByZero exception bubbles up the stack and eventually gets eaten by the native code that sits upstream from your event handler.

Now this behavior can result in some serious headscratching for the application developer. In most real-world cases, the bug is not as easy to spot as the one in my simplistic example. To avoid getting into these kind of issues, I recommend that you put your ink event handling code in try/catch blocks, so you can respond to exceptions thrown by your code, before they get eaten by the native/managed interop. Something along the lines of:

void _inkOverlay_Stroke(object sender, InkCollectorStrokeEventArgs e)

{

try

{

int foo = 2;

int bar = 5 / (2 - foo);

e.Stroke.DrawingAttributes.Color = Color.Red;

this.Invalidate();

}

catch (Exception exc)

{

MessageBox.Show(exc.ToString());

}

With this, the MessageBox will now tell you that there was a DivideByZero exception, and it will tell you where it happened.

Next post in this series: TabletPC Development Gotchas Part2: Deploying InkPicture applications to Windows XP desktops

Fun with Ink & Xaml - Part1: Ink Reflections

swick — Thu, 01 Nov 2007 00:44:00 GMT

With the InkCanvas element in WPF you can create stunning inking experiences for TabletPC users (mouse users can play along, too!). Several very cool scenarios can be enabled just by writing markup - without any additional code behind.

Here is a first example: an ink input field (takes input from either stylus or mouse) that has a dynamic reflection effect. While the user is inking, the reflection gets updated dynamically, in real-time. Implemented entirely in markup.

The key feature (besides InkCanvas) here is the VisualBrush. The bottom part of the scene is a Rectangle that gets painted with a VisualBrush that is bound to the ink input control. As a result it gets updated dynamically as the user draws onto the control. Below is the relevant piece of markup. The full XAML file is attached to this post. You can load it into XamlPad to play with it, or just open in IE and ink away.

<Rectangle.Fill>
    <VisualBrush
      Visual="{Binding ElementName=inkBorder}">
      <VisualBrush.RelativeTransform>
        <TransformGroup>
          <ScaleTransform ScaleX="1" ScaleY="-1" />
          <TranslateTransform Y="1" />
        </TransformGroup>
      </VisualBrush.RelativeTransform>
    </VisualBrush>
</Rectangle.Fill>

More information about creating reflections using VisualBrush can be found in this MSDN How-To Topic. Additional How-To topics on Ink in WPF are also available on MSDN.

Next post in this series: Fun with Ink & Xaml - Part2: Zoom and Scroll

.NET 3.5: Viewport2DVisual3D and Ink

swick — Wed, 31 Oct 2007 22:59:00 GMT

WPF 3.5 includes an exciting new feature: Viewport2DVisual3D. It makes building interactive 3D experiences very easy and is nicely integrated with the rest of the WPF Platform. I have used this feature to write a new version of the "Ink Postcard" sample that I wrote a few years back for the Windows SDK. A VS project that contains the new and improved version is attached to this post (you need .NET 3.5 installed to run it).

The sample allows you to draw ink directly onto a 3D model (a Postcard in this case) - even when it is animated! It demonstrates how well this new feature is integrated with things like Ink, Animation, InkCanvas and input from mouse and stylus (when running on a TabletPC).

More information on Viewport2DVisual3D and other great samples around this can be found on Lester's WPF Blog and on Greg Schlechter's Blog.