Stefan Wick's Weblog - Tips for WP7, Silverlight, WPF and Tablet PC

WP7 Mango: Image Download With Custom Referer Header

Stefan Wick - MSFT — Thu, 04 Aug 2011 07:14:00 GMT

In Mango we have enabled setting the referer header (and many other headers) on HttpWebRequests. One question that popped up a few times: how do I use this with the Image element and data-binding to download my images. Here is a quick sample to demonstrate how you can do this.

1. Step: define a custom attached property on Image that takes the URI to your image.

2. Step: implement the download piece when the property changes and customize the header as needed.

3. Step: Now use your brand new property in your app's XAML.

Full sample project is attached.

Demos from my MIX 2011 session - Part 1: Navigation Tips

Stefan Wick - MSFT — Tue, 19 Apr 2011 06:26:00 GMT

I have attached the first of the demos from my MIX 2011 session. Note that I have attached two versions: the 'before' version to illustrate the problems, and the 'after' version to show the fixes. This post will walk you through each of the tips and describes the code changes being made:

Tip 1: Circular Navigation

Consider the following sequence in the demo app: Log in (empty user/pwd) -> Send a Message -> type something -> hit 'Home' button (in the App Bar) -> Get Stock Quotes -> hit 'Home' button -> Send a Message. While you do this, please monitor the helper control on the top right, which shows you the current navigation backstack. The result will look like this:

There are two small problems here that will likely confuse the user: (a) the user didn't get back to the message they were typing and (b) the user is deeper in the navigation stack than likely intended. To solve this and avoid confusion, you have two options (I chose option A for my demo):

Solution A: Avoid Circulation Navigation altogether. In this case, just get rid of the 'Home' App Bar Buttons and the user will be just fine using standard means of navigation.
Solution B: Instead of navigating forward to 'Home', walk the backstack programmatically, until you reach the Start Page. More details in this white paper by Yochay Kiriaty.

Tip 2: Dealing with transient Pages on the Backstack

If you now hit the back button a couple of times from the current state of the app, you will notice two issues: (a) we get back to the LoginPage and (b) we can't exit the app as the back key seems to get stuck. The latter is big no-no and will cause your app to fail certification. It's an easy fix though as the app was just marking the back key as handled for no valid reason, so removing the highlighted line will fix this:

protected override void OnBackKeyPress(System.ComponentModel.CancelEventArgs e)
{
e.Cancel = true;
base.OnBackKeyPress(e);
}

But how do we fix the root problem of hitting the LoginPage on our way back and exit the app cleanly? Again there are a few options to fix this. My personal preference is the following: I consider the LoginPage semantically not really a page that participates in navigation, but rather a control that overlays the StartPage and is shown only if the StartPage is navigated to without an existing user context. To implement this, I just move LoginPage code into a control (LoginControl) and include that in the StartPage. The StartPage now can control the visiblity of the LoginControl programatically as needed.

For completeness sake, alternate methods for solving the problem of dealing with transient pages on the backstack include cancelling the navigation or using UriMapper. Peter Torr has a blog post covering both.

Tip 3: Saving Page state on Tombstoning

Consider the following scenario in the demo app: We navigate to the "Send a Message" page and start typing a message. Now we want to find some data on the Internet and use copy & paste to include it in the message. For that we hit the Search button in the App Bar, do our search and then navigate back. The result is very frustrating: the message that we had typed tediously is now gone. Why is that, what happened here? Tombstone happened!

The short story is this: when the user navigates forward, away from your app, then your app will receive an entry on the global backstack, get a chance to save its state and then the process will be shut down. The longer story is documented here. So the problem in the demo app was that we didn't save our state before we got Tombstoned. The general recommendation for saving your Page's state is to persist it in OnNavigatedFrom() and restore it in OnNavigatedTo(), in MessagePage.xaml.cs:

protected override voidOnNavigatedFrom(NavigationEventArgs e)

{

base.OnNavigatedFrom(e);

if (App.CurrentNavigationMode != NavigationMode.Back)

{

this.State["message"] = tbMsgBody.Text;

}

protected override voidOnNavigatedTo(NavigationEventArgs e)

{

base.OnNavigatedTo(e);

if (this.State.ContainsKey("message"))

{

tbMsgBody.Text = this.State["message"] as string;

}

I want to point out one small optimization I have made here in the OnNavigatedFrom() call: I will not save the state if my navigation goes backwards. This is because when going backwards, the current page (and its state) drops off the backstack. There is no way the user could ever come back to that page instance, so there is no need really to persist that state. In this app it doesn't buy us much performance gain, but on pages that save large amounts of data, you can save precious CPU and battery with this optimization. Unfortunately, it's not completely straight forward to figure out the navigation mode, so I had to build a little static helper property. It's something we want to improve in the next version.

Tip 4: Saving Application state on Tombstoning

Since the state is being saved on a per page basis, it is important to perform Tombstone tests for each page in our app. So let's start a fresh instance of our app and test the Stock Quote Page: After the quotes are downloaded, hit the Windows button to navigate forward (which will Tombstone our app). Now watch what happens when we come back to our app: Without debugger you will just see a little flicker and then you are back at the start screen. With debugger attached you will see that we are crashing in the constructor of the StockPage class.

public StockPage()

{

InitializeComponent();

tbCurrentUser.Text = "CurrentUser: " + App.CurrentUser.Name;

this.Loaded += new RoutedEventHandler(StockPage_Loaded);

}

The reason for this is fairly simple: the constructor assumes that the static Application property for the user context is always set (since it's set during Login), however this won't be true when returning from Tombstone, if we don't preserve the application state correctly. The general recommendation for saving global app state is to do this in the Deactivated event and then restore it in the Activated event. The latter was missing in the demo app, hence the crash. So now we are adding the highlighted line to fix this problem (in App.xaml.cs):

private void Application_Activated(object sender, ActivatedEventArgs e)

{

App.CurrentUser = PhoneApplicationService.Current.State["userContext"] as UserContext;

}

private void Application_Deactivated(object sender, DeactivatedEventArgs e)

{

PhoneApplicationService.Current.State["userContext"] = App.CurrentUser;

}

With these four tips/fixes, our app is now much more robust and consistent from a navigation perspective compared to where we started. There are still some other problems in the app, related to the various different phones states though. This will be the topic of my next blog post.

MIX 2011: My Windows Phone 7 Session

Stefan Wick - MSFT — Sat, 16 Apr 2011 14:20:00 GMT

I just got back from Las Vegas where I had the opportunity to attend and speak at the MIX 2011 conference. A recording of my session can be viewed here on Channel9: Expert Lessons: Top Tips for Building a Successful Windows Phone Application

I had a great time at MIX and I am very excited about the new Windows Phone Mango features we announced as well as all the cool stuff that is coming in Silverlight 5. Watch the Day 2 Keynote for some great demos around the new features. The Silverlight 5 Beta is available for download now here, the Windows Phone Mango Tools/Emulator will become available a little later next month.

This weekend I will work on some follow-up posts to my MIX session and get the demo/samples uploaded here. Stay tuned ... :-)

Update (4/20): attaching my slide deck

Image Tips for Windows Phone 7

Stefan Wick - MSFT — Fri, 08 Apr 2011 05:43:00 GMT

If you are developing for Windows Phone you have probably been using the the Image element in various places of your UI already. Using the Image element is very easy and wouldn't warrent a blog post: just set the Source property to the URI of your image and you are done, right? Yeah, pretty much - however, there are a couple subtle details that are very useful to know, especially if you want to optimize your app for best performance and memory usage. Most of these little tips aren't specific to the phone - they apply also to Silverlight desktop - but on the phone it is so much more important to pay attention to the little performance details that can turn a good app into an awesome app. To help illustrate the points, I have attached a sample app that demonstrates the results you can achieve by applying these tips.

JPG vs. PNG

If you can make a choice between using JPG and PNG, choose JPG for all your opaque images. The JPG decoder in the Windows Phone 7 operating system is considerably faster than the PNG decoder. If you need to use images that have transparency, PNG is your only choice though.

Resource vs. Content

Images (or any files for that matter) that are part of your Windows Phone XAP can have their "Build Type" set to either "Resource" or "Content" in Visual Studio. At first sight it doesn't seem to make any difference what you choose here, as in both cases your files end up getting packaged up in the XAP. The difference becomes visible when you crack open your XAP (rename it to .zip and unzip it): now you can see all your files of type "Content", but you won't find the files of type "Resource" because those are embedded in the assemblies (.dll files). OK, why do I care? You care because the larger your application's DLL, the slower your app will launch. On the other hand, once they are loaded the images will show up quicker compared to having them load from disk later. Summary: include your images as "Content" to optimize for quick start up, include them as "Resource" to optimize for quick access.

The other thing to note as that there is a difference in URI syntax for images included as "Content" vs. "Resource". Check out the attached sample and navigate to the "Content vs. Resource" page for more details on this.

Content: <Image Source="/ImagesAsContent/smiley1.png"/>

Resource: <Image Source="..\ImagesAsResource\smiley3.png"/>

Async vs. Sync Loading of images

If you drill a little deeper into the Imaging APIs you will come across the BitmapImage class, which is doing most of the work behind the scenes when you create an Image. It can load things in two different modes:

BitmapImage.UriSource = uriSource; // loads the image via URI, asynchronously
BitmapImage.SetSource(stream); // loads the image from stream, synchronously

Note that loading the image asynchronously doesn't mean it will happen completely off-thread. This is because currently the image decode is happening on the UI thread. For some more information about asynchronous loading of images while keeping the UI thread responsive check out this blog post by David Anson.

Some more trivia about async vs. sync loading:

If you load an invalid image file synchronously, you will get an exception
If you load an invalid image file asynchronously, the ImageFailed event fires (if you are subscribed)
If you load an valid image file asynchronously, the ImageOpened event fires when it's done loading
If you load an valid image file synchronously, the ImageOpened event does not fire

To these differences in action check out the attached sample and navigate to the "Loading" page:

Image Caching

This is an important one, and MSDN is currently fairly silent about it. If you were ever wondering why your image memory didn't get released after clearing the Source and removing the Image from the tree, you were most likely seeing Image caching in action. This is an intended performance optimization, to avoid (down)loading and decoding the same image over and over again. Instead we keep a cache in memory that we can easily and quickly reuse. This is not to confuse with the browser cache for downloaded files.

While this is a nice and free performance optimization, at times it can blow your memory unnecessarily, especially when you cycle through many images that you will never come back to. Their cache will use up memory for the lifetime of your app. The good news is that you can delete the cache when you decided that you no longer need it:

BitmapImage bitmapImage = image.Source as BitmapImage;

bitmapImage.UriSource = null;

image.Source = null;

Being smart about this can save you quite a bit of memory usage, which is a precious resource on a phone device. In the sample app, go to the "Caching" page and monitor the memory usage as you show/clear the image. Then check the box and try again. You will see a difference of ~3MB in the example case.

BitmapCreateOptions

This is a quick, yet interesting one. If you create BitmapImage objects by hand, you might wonder why it doesn't report the size of the image after you think it's done creating the image. This is because by default the CreateOptions property is set to "DelayCreation", which means that the object really gets created only when it's indeed needed, meaning the BitmapImage is assigned as the source of an Image element or an ImageBrush that are in the live tree. This allows creating collections of BitmapImages up front on start up, without having to pay all the cost (CPU & memory) until the app actually needs the respective images. If you want to force immediate creation, set the CreateOptions to "None". There is another option (IgnoreImageCache) that isn't terribly useful for many practical purposes, but it's needed by the design tools (e.g. Blend).

In the sample app, if you go to the "CreateOptions" page, go through the Create/Show/Clear sequence once with CreateOptions=DelayCreation and once with CreateOptions=None and monitor the Size value to see the difference in action.

Custom Decoding

By default the Imaging APIs will decode images in their natural resolution (except when auto-downsampling, more about that later). However, in many cases this is more than you actually need on a phone display. If you are downloading a collection of 320x320 images from a service only to display them as 32x32 thumbnails, you would be wasting a lot of memory if you decode them at their natural resolution.

On Windows Phone (specifically, not on desktop) the platform provides the PictureDecoder API that allows to specify the resolution you want to decode to:

image.Source = PictureDecoder.DecodeJpeg(jpgStream, 192, 256);

Note: in the current release there is an unfortunate bug in this API as the values for width and height are swapped. To workaround it just pass your width into the height parameter and vice-versa. This will be future compatible, as we will fix this with a quirks mode for existing apps.

To see the memory gains from doing this, open the sample app and navigate to the "Custom Decoding" page. Switch between the two resolutions and monitor the memory usage.

Auto Downsampling

This is the last piece of need-to-know trivia when dealing with images in Silverlight for Windows Phone 7. The background is that individual elements are limited to 2048x2048 size on Windows Phone 7. Anything beyond that will be clipped. This means that if you want to consume an image that is larger than 2048 pixels in either dimension, it will not show correctly/completely. To avoid this potential confusion, the platform automatically downsamples large images so that they fit into 2048x2048. This is different from desktop Silverlight where this limitation does not exist.

In the sample app I am consuming an image of size 3000x2102, which subsequently gets downsamples to 1500x1051.

Phew, this post was longer than I thought it would be. Turns out there are a lot of little things to learn about Images in Silverlight for Windows Phone 7. Thanks for reading this far and I hope you found this post and the attached sample app helpful.

A (slightly) new direction

Stefan Wick - MSFT — Fri, 08 Apr 2011 00:03:00 GMT

For the last 18 months I have been (and I still am) working on an exciting new project: Silverlight for Windows Phone 7. I haven't had much of a chance to continue my posts about Silverlight, Tablet PC etc., but I am planning pick this up again now and post some hopefully useful tips and samples here. Those will mostly be about building (and testing) Silverlight apps for Windows Phone 7, so that is a bit of a change in direction from the past.

Stay tuned for more.

Cheers, Stefan Wick

Silverlight 4 OOB - Handwriting Recognition & Text-To-Speech

Stefan Wick - MSFT — Thu, 07 Apr 2011 21:42:00 GMT

I have been sitting on this sample for quite a while, but never found the time to get it ready for a post. Before I switch the focus of my blog over to Windows Phone 7 development, I wanted to get this out of the way first :-)

With Silverlight 4, we introduced an exciting new capability for Out-Of-Browser apps: Trusted Applications - one of the key new fatures of Trusted Applications is the ability to integrate with COM Automation interfaces on your Windows PC. What does this mean? This allows you to call into native components on your system that are either provided by the OS or installed by the user or system admin. On MSDN you can find some sample code for the canonical example that highlights the power of this feature: integrating Microsoft Office features into your Silverlight application.

In this blog post, however, I want to show some other cool things you can do with these new APIs on your PC: I want to use the systems handwriting recognizer as well as the systems speech synthesizer within my Silverlight application. Let's do the easy part first and take a look at how we get the speech synthesis done (in the attached sample, this plays back the recognized handwriting):

1	private void btnSpeak_Click(object sender, RoutedEventArgs e)
2	{
3	dynamic spVoice = AutomationFactory.CreateObject("SAPI.SpVoice.1");
4	spVoice.Speak(tbResult.Text);
5	}

In line 3 we create an instance of the SAPI.SpVoice (SAPI = Microsoft Speach API). Now we can just call the Speak() method (line 4) in order to have the desired text spoken by the machine. Make sure you turn on your speakers.

For the handwriting recognition part, the code looks a little bit more complicated, mostly for two reasons: The COM Automation API for Ink has some oddities & we need to convert the users strokes from pixel space into HiMetric. Here is the full code needed to implement this as extension method on Inkpresenter to have its writing recognized by the system's handwriting recognizer:

1	private const double HiMetricFactor = 26.46d; // = 1000 * 2.53 / 96
2	public static string Recognize(this InkPresenter presenter)
3	{
4	dynamic recognizers = AutomationFactory.CreateObject("msinkaut.InkRecognizers");
5	dynamic reco = recognizers.GetDefaultRecognizer(1033);
6	dynamic context = reco.CreateRecognizerContext();
7	dynamic inkCol = AutomationFactory.CreateObject("msinkaut.InkCollector");
8	dynamic ink = inkCol.Ink;
9
10	foreach (Stroke stroke in presenter.Strokes)
11	{
12	int[] packets = new int[stroke.StylusPoints.Count * 2];
13	for (int i = 0; i < stroke.StylusPoints.Count; i++)
14	{
15	packets[i * 2] = (int)(stroke.StylusPoints[i].X * HiMetricFactor);
16	packets[i * 2 + 1] = (int)(stroke.StylusPoints[i].Y * HiMetricFactor);
17	}
18	dynamic inkStroke = ink.CreateStroke(packets, null);
19	}
20
21	context.Strokes = ink.Strokes;
22	dynamic result = context.Recognize(null);
23	return result.TopString;
24	}

If you are a little lost, that's OK. Here is how/why it works: :-)

On line 1 we just define the conversion factor for pixels to HiMetric (the coordinate space used by the native handwriting recognizer on the Windows system). Lines 4-6 are all about getting us a new RecognizerContext, which is the primary interface for the native recognition engines. In lines 6-7 I am using a little trick to get a new empty Ink object. There is no Automation-compliany way to produce one, but I can create an InkCollector that owns an Ink object. Then I can steal it for my purpose. All of lines 10-19 are about converting the Silverlight Stroke data (from pixels) into native Stroke data (in HiMetric). Last but not least, in lines 21-23 we pass the Strokes down to the recognizer have have them recognized synchronously.

The full source code for the sample is attached to this post. When you run it, please be sure to run it as Out-Of-Browser app, because Trusted Application features aren't supported in the browser in Silverlight 4.

Enjoy! :-)

Silverlight 3: Perspective 3D

swick — Wed, 18 Mar 2009 10:24:00 GMT

Silverlight 3 Beta has been released today. This release includes a number of exciting new features that I want to illustrate with a series of quick samples on my blog. (more info on Silverlight 3 Beta and how to get the bits and tools).

The first new feature I want to show is Perspective 3D transformation. We have added a powerful new property 'Projection' to UIElement that lets you rotate and move any element in your tree in 3D space! The usage is very simple, no complicated math required - just set the Projection property to a PlaneProjection in XAML or code and specify how you want to rotate or move your elements. You can then change these properties dynamically at runtime, either through code or animations.

<Grid >

<Grid.Projection>

</Grid.Projection>

</Grid>

(More info on Perspective 3D in Silverlight 3 Beta)

Below is a live example of this new feature in action. The source is attached to this post. Note that you need the Silverlight 3 Beta Tools for VS in order to build the project. To view the live sample on this page you just need the Silverlight 3 Beta runtime installed. In the sample I have two surfaces back-to-back to each other, simulating a postcard in 3D space. Use the sliders to rotate the postcard around x, y or z axis. To demonstrate that the projected visuals are actually live and also take input, I have ink-enabled then, so you can draw on either side of the postcard.

The below sample has been update for the Silverlight 3 RTW Runtime (download)

Custom Ink Rendering in Silverlight 2

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

Drawing ink with the built-in stroke objects works great for handwriting and annotations. In some scenarios, however, you may want something more fancy that takes advantage of Silverlight's rich graphics capabilities.

Creating ink strokes with a customized appearance is fairly straight forward with Silverlight 2. You basically collect StylusPoints in mouse events as usual, but instead of adding them to stroke objects, you just draw your own geometries or shapes at the stylus/mouse location.

When collecting sample points during the MouseMove event, please be sure to call the StylusDevice.GetStylusPoints() method and process all points returned from that call. This will ensure that stylus users will get the full fidelity of input points, since their pointing device reports points more often than the MouseMove events fires. Also it is good practice to interpolate points between sample points, since they won't usually be equidistant.

I have a attached a sample project that demonstrates the concept end-to-end using Ellipse shapes with a LinearGradientBrush to give my ink strokes a custom look. Below is live version of the sample for you to play with.

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;

}

Erasing Ink in Silverlight 2

swick — Sun, 30 Nov 2008 18:09:00 GMT

Another frequently asked question around inking in Silverlight is about erasing Ink strokes after they have been collected or loaded. Unlike WPF or the Tablet SDK for COM & Winforms, Silverlight does not come with controls that have built-in eraser modes in the box. However, with a little bit of code-behind you can implement those modes and adjust them to your specific needs. The key APIs you will need for this are StrokeCollection.HitTest() and Stroke.HitTest(). Both APIs take a collection of StylusPoints as input and they return a value indicating whether or not the ink stroke(s) have been hit. Based on that you can then modify your collection accordingly to represent the result of the erase operation. Popular inking apps (e.g. Windows Journal) offer two different modes of erasing:

Erase By Stroke:
Implementing this mode is fairly straight forward. Just pass the stylus points collected along the eraser path into the HitTest() method of your collection of ink strokes and the API will tell you which strokes to remove from your collection.

Erase By Point:
This one takes a little more effort to get right. We start like above, but then we don't remove the hit strokes. Instead, we figure out which segment of the stroke was hit (by using the Stroke.HitTest() API) and then we split the stroke by removing that segment.

I have attached a sample that implements both modes. You can also check out a live version of the sample below. The simplistic implementation of "Erase By Point" in the sample leaves some areas of improvements for the reader (or for a future blog post). Most notably, the size the chunk erased in this mode is not very consistent as it depends on several factors (distance points, location of the hit point, thickness of the stroke, etc.). A good improvement would be to add some logic that ensures the eraser always cuts a consistent chunk out of the ink strokes.

Saving Ink to IsolatedStorage with Silverlight 2

swick — Sat, 01 Nov 2008 21:38:00 GMT

One of the questions I have seen quite a few times in the Silverlight.net forums is how to persists (and de-persists) ink in Silverlight 2. Unlike WPF, Silverlight does not support a binary persistence format (ISF), but you can write some code to save and load ink to and from XAML. To demonstrate how to do this in a real world example, I am using another very cool feature in Silverlight 2: IsolatedStorage

IsolatedStorage is a per application, per computer, per user storage that offers a powerful, easy to use way for your web applications to store data locally on the user's and retrieve it later when the user visits your sites again on the same computer. You can use it like a file system, or as in the case of this example, simply use it to store application settings in key/value pairs. Learn more about how to do the latter here.

The goal of my application is to store the ink as XAML in IsolatedStorage when the user navigates away from the site. Upon return, the app will retrieve the persisted data from the storage, depersist it and present the ink to the user. Here are the relevant pieces of code (full code project is attached to this post).

Serializing and de-serializing ink strokes using XAML:

public string InkXAML

{

get

{

// persists ink strokes to XAML

StringBuilder builder = new StringBuilder();

XmlWriter writer = XmlWriter.Create(builder);

writer.WriteStartElement("StrokeCollection",

"http://schemas.microsoft.com/winfx/2006/xaml/presentation");

foreach (Stroke stroke in _presenter.Strokes)

{

writer.WriteStartElement("Stroke");

writer.WriteStartElement("Stroke.DrawingAttributes");

writer.WriteStartElement("DrawingAttributes");

writer.WriteAttributeString("Width",

stroke.DrawingAttributes.Width.ToString(invCult));

writer.WriteAttributeString("Height",

stroke.DrawingAttributes.Height.ToString(invCult));

writer.WriteAttributeString("Color",

string.Format(invCult, "#{0:X2}{1:X2}{2:X2}{3:X2}",

stroke.DrawingAttributes.Color.A,

stroke.DrawingAttributes.Color.R,

stroke.DrawingAttributes.Color.G,

stroke.DrawingAttributes.Color.B));

writer.WriteAttributeString("OutlineColor",

string.Format(invCult, "#{0:X2}{1:X2}{2:X2}{3:X2}",

stroke.DrawingAttributes.OutlineColor.A,

stroke.DrawingAttributes.OutlineColor.R,

stroke.DrawingAttributes.OutlineColor.G,

stroke.DrawingAttributes.OutlineColor.B));

writer.WriteEndElement();

writer.WriteStartElement("Stroke.StylusPoints");

writer.WriteStartElement("StylusPointCollection");

foreach (StylusPoint sp in stroke.StylusPoints)

{

writer.WriteStartElement("StylusPoint");

writer.WriteAttributeString("X", sp.X.ToString(invCult));

writer.WriteAttributeString("Y", sp.Y.ToString(invCult));

writer.WriteEndElement();

}

writer.WriteEndElement();

}

writer.WriteEndElement();

writer.Flush();

return builder.ToString();

}

set

{

// depersist ink strokes from XAML

try

{

_presenter.Strokes = XamlReader.Load(value) as StrokeCollection;

}

catch (Exception exc) { Debug.WriteLine(exc.ToString()); }

}

Persisting data on Application exit:

void Application_Exit(object sender, EventArgs e)

{

IsolatedStorageSettings settings = IsolatedStorageSettings.ApplicationSettings;

string inkXAML = _inkCollector.InkXAML;

if (settings.Contains("Ink"))

{

settings["Ink"] = inkXAML;

}

else

{

settings.Add("Ink", inkXAML);

}

Loading data on Application startup:

public Page()

{

InitializeComponent();

_inkCollector = new InkCollector(inkNote);

IsolatedStorageSettings settings =

IsolatedStorageSettings.ApplicationSettings;

string inkXAML = "";

if (settings.Contains("Ink"))

{

inkXAML = settings["Ink"] as string;

_inkCollector.InkXAML = inkXAML;

}

If you have Silverlight 2 installed (who hasn't? :-)), you can try it out live below. Draw some ink, navigate away, close the browser, clear the cache, etc. Then return to my blog and see that your ink is back, due to the power of IsolatedStorage.

TabletPC Development Gotchas Part 7: Detecting the input device in Silverlight 2

swick — Sat, 01 Nov 2008 20:07:00 GMT

When writing an application that supports multiple input devices (mouse, stylus, touch) it is often neccessary to detect which type of device is sending the input events.Silverlight 1.0 offered a DeviceType property on the StylusInfo object that gets reported in every mouse event.

In the Silverlight 2 managed API, you will not find an equivelnt object that provides this information. We omitted it on purpose in this release, because adding this to the OM could not be done in a way that would make the Silverlight API a compatible subset of the WPF API. In future versions of both platforms we will provide a consistent way to get to this information.

Omitting this for now is acceptable since we do provide a workaround to get to this information, via the HTML DOM bridge. Here is how you do it (full source attached):

Expose a scriptable method from managed code to handle the DeviceType information:

public Page()

{

InitializeComponent();

HtmlPage.RegisterScriptableObject("page", this);

}

[ScriptableMember]

public void SetDeviceType(string deviceType)

{

_deviceType = deviceType;

switch (_deviceType)

{

case "Mouse":

// add specific code for mouse

break;

case "Stylus":

// add specific code for stylus

break;

case "Touch":

// add specific code for touch

break;

}

Hook up to the MouseLeftButtonDown event in JavaScript and pass the StylusInfo.DeviceType information to managed code when the event fires:

function onSilverlightLoad(sender, args) {

// attach a JavaScript MouseDown event handler

var inkPresenter = sender._element.content.findName("inkPresenter");

inkPresenter.addEventListener("mouseLeftButtonDown", onMouseDown);

}

function onMouseDown(sender, args) {

// get the device type info and pass

// the information to the managed code

var stylusInfo = args.getStylusInfo();

var plugin = sender.getHost();

plugin.content.page.SetDeviceType(stylusInfo.deviceType.toString());

}

</script>

Now, as a proud owner of a Toshiba M700, I can run the solution and collect ink from different devices and the app automatically changes the pen attributes as I switch between input devices. Here is a screenshot showing ink strokes collected with the three different devices available on my Tablet PC:

Silverlight 2 Released - Write On!

swick — Tue, 14 Oct 2008 08:45:00 GMT

Now that Silverlight 2 is released, I finally got around to updating my blog after a long time of silence. For those of you interested in handwriting and Tablet related technologies, I want to start out with a canonical example of a Silverlight 2 Inking application. There have been a couple of OM changes since Beta1 around ink and stylus in Silverlight, mostly in order to make the Silverlight API more consistent with the WPF Ink/Stylus APIs.

Just like in Silverlight 1.0, the key element to inking is the InkPresenter which is a Canvas-like element with the ability to render ink strokes. To bring it to live and actually enable ink collection (and eraser) funtionality you will need to write some code-behind that responds to the user's input. In my example I have encapsulated the required code into a re-usable 'InkCollector' class (in InkCollector.cs), so you can just instantiate and assign it to your InkPresenter in order to get started with inking in your own projects.

Here is my example - source code attached - try it out by using your mouse or stylus to write and erase ink:

Ink in Silverlight 2 (Beta 1)

swick — Tue, 25 Mar 2008 15:07:00 GMT

I am very excited to write my first blog post about Silverlight 2 today, the project I am currently working on. In early March 2008 we shipped a public Beta for Silverlight 2 that you can download (along with all the neccessary tools) from http://silverlight.net/.

Today I want to introduce you to using Ink in your Silverlight 2 application, using the new managed object model. This post has two versions of a basic inking sample attached - a C# version and a VB.NET version. Let's take a look at the XAML first. The relevant piece here is the InkPresenter element, which is our inking surface that will host the ink strokes collected by the user:

<InkPresenter x:Name="inkCtrl" Cursor="Stylus"

MouseLeftButtonDown="inkCtrl_MouseLeftButtonDown"

MouseMove="inkCtrl_MouseMove"

MouseLeftButtonUp="inkCtrl_MouseLeftButtonUp"/>

Now we need to add a little bit of code behind in the mouse event handlers in order to collect strokes from the user's input. Note that the 'GetStylusPoints()' calls actually obtain the high fidelity stylus input when using a stylus, so you get optimal, smooth ink on a Tablet PC - or with an external Tablet input device on your desktop.

public partial class Page : UserControl

{

public Page()

{

InitializeComponent();

}

private void inkCtrl_MouseLeftButtonDown(object sender,

MouseButtonEventArgs e)

{

// capture mouse and create a new stroke

inkCtrl.CaptureMouse();

newStroke = new Stroke();

inkCtrl.Strokes.Add(newStroke);

// set the desired drawing attributes here

newStroke.DrawingAttributes.Color = Colors.Blue;

newStroke.DrawingAttributes.OutlineColor = Colors.Yellow;

newStroke.DrawingAttributes.Width = 6d;

newStroke.DrawingAttributes.Height = 6d;

// add the stylus points

newStroke.StylusPoints.AddStylusPoints(e.GetStylusPoints(inkCtrl));

}

private void inkCtrl_MouseMove(object sender,

MouseEventArgs e)

{

if (newStroke != null)

{

// add the stylus points

newStroke.StylusPoints.AddStylusPoints(e.GetStylusPoints(inkCtrl));

}

private void inkCtrl_MouseLeftButtonUp(object sender,

MouseButtonEventArgs e)

{

if (newStroke != null)

{

// add the stylus points

newStroke.StylusPoints.AddStylusPoints(e.GetStylusPoints(inkCtrl));

}

// release mouse capture and we are done

inkCtrl.ReleaseMouseCapture();

newStroke = null;

}

private Stroke newStroke = null;

}

And here is the result at runtime, after collecting a couple of strokeson my Tablet PC:

For a more advanced sample app that uses ink to annotate pictures and has support for erasing ink, please visit the Silverlight 2 Beta1 Gallery and look for the 'Image Snipper' sample. You can also run it directly from the below IFrame (requires the Silverlight 2 Beta1 runtime to be installed on your computer):

<embedded sample removed, since Silverlight 2 Beta1 is no longer relevant>

Silverlight Ice Skaters - a Holiday Greetings eCard

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

In the spirit of the holiday season, I have created a little eCard using the Silverlight v1.0 SDK. Use the buttons to add ice skaters and falling snow to the scene :-)

Have a wonderful Holiday and a happy New Year 2008!

P.S. I am using the Silverlight Streaming Service to host the eCard. If you like it, you can embed it on your site by using the following HTML:

The source code for the eCard is attached to this post.

TabletPC Development Gotchas Part 6: InkCanvas Element Selection/Move/Resize

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

WPF's InkCanvas element provides a lot of built-in functionality for several common, ink-related tasks like stylus gesture recognition, point and stroke erase, as well as the selection, resizing and moving of ink strokes. The key to those features is the 'EditingMode' property - which is nicely demonstrated in the InkCanvas EditingModes SDK sample (btw, it also demonstrates an implementation of an Undo/Redo stack for ink operations).

One little known, yet very cool feature is not demonstrated in this sample, though: The selection, resizing and moving functioality (i.e. EditingMode="Select") can not only be applied to ink strokes, but also to child elements of the InkCanvas. This can be very handy if you want to build, for example, a note-taking application that can also host text, pictures and other content besides the handwritten ink. You can then use the 'Select" mode to let the user re-arrange and resize all their content.

The "gotcha" I wanted to point in this blog post is a limitation in this feature: Child elements in an InkCanvas may be positioned in a variety of different ways: for example you can position them by setting a "Margin" or by setting any combination of "Canvas.Left/Right/Top/Bottom" attached properties. InkCanvas's selection/moving/resizing feature, however, only works on elements that have absolute positioning set via "Canvas.Left/Top".

Let's look at the following example markup:

<Window x:Class="InkCanvasElementSelection.Window1"

xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

Title="InkCanvasElementSelection"

ResizeMode="NoResize"

Height="450" Width="450">

<Window.Resources>

</Style>

</Window.Resources>

<Grid>

<InkCanvas Name="inkCanvas" EditingMode="Select"

Background="LightGoldenrodYellow"

SelectionChanging="OnSelectionChanging">

<Rectangle.RenderTransform>

</Rectangle.RenderTransform>

</Rectangle>

</InkCanvas>

</Grid>

</Window>

Note that the markup subscribes to the 'SelectionChanging' event on the InkCanvas. Let's leave the implementation of that event handler empty for now to demonstrate the limitation. Also note that the four rectangles use different ways to position themselves on the InkCanvas. Only the blue rectangle uses the "Canvas.Left/Top" attached properties for positioning.

Now you can use the lasso tool to select one or more elements, and then try to move and resize them. You will notice that it only works correctly for the blue rectangle (because that one has been positioned via "Canvas.Left/Top"). For the other rectangles you won't get the desired move or resize results.

Now what can I do if there are child elements that have not been positioned via "Canvas.Left/Top"? Here is a workaround to make this feature work even for those elements: In the 'SelectionChanging' event - which fires whenever you change what content is selected - you can walk the list of child elements and ensure they are positioned via "Canvas.Left/Top". Here is a piece you can add to the above sample to demonstrate this approach:

void OnSelectionChanging(object sender, InkCanvasSelectionChangingEventArgs e)

{

ReadOnlyCollection<UIElement> elements = e.GetSelectedElements();

foreach (UIElement element in elements)

{

// obtain actual location of element relative to InkCanvas

Point locationInInkCanvas = element.TranslatePoint(new Point(0, 0),

inkCanvas);

// set the location via Left/Top properties

element.SetValue(InkCanvas.LeftProperty, locationInInkCanvas.X);

element.SetValue(InkCanvas.TopProperty, locationInInkCanvas.Y);

// un-set right/bottom properties

element.SetValue(InkCanvas.RightProperty, double.NaN);

element.SetValue(InkCanvas.BottomProperty, double.NaN);

// re-translate any render transform

Matrix matRender = element.RenderTransform.Value;

matRender.Translate(-matRender.OffsetX, -matRender.OffsetY);

element.RenderTransform = new MatrixTransform(matRender);

// set margins to zero

if (element is FrameworkElement)

{

((FrameworkElement)element).Margin = new Thickness(0d);

}

Now if re-run the sample you will find all rectangles from the original markup can be selected, moved and resized as expected:

Full source code of this example is included in the attached Visual Studio project.

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:

Ink Reflections - in Silverlight

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

I have received several question from folks about my earlier post on Ink Reflections in WPF. People were curious how to accomplish the same or a similar effect in Silverlight, in the absence of the VisualBrush object.

Clearly, WPF's VisualBrush is the main object that enables scenarios like this and it definitely makes their implementation straightforward. However, in Silverlight you can also accomplish effects like this with little bit of extra coding.

First of all, Silverlight has an ImageBrush and a VideoBrush, so as long as the visul you want to mirror is an image or a video, you can apply the same technique as used in my WPF sample and you are done.

If you want to mirror a different type of visual, you will have to manage the mirror yourself, meaning you have to create a secondary, mirrored visual and update it whenever the original changes.

I have created a sample that demonstrates both techniques together. The yellow background with silver border is an image that gets mirrored using an ImageBrush. The ink you draw (and erase) gets mirrored programmatically using some JavaScript code-behind.

The sample's source code is attached. A live version, hosted via Silverlight Streaming, is included below for you try out.

Rendering ink and image to a bitmap using WPF

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

To follow-up on my previous blog post and to complete the story about rendering ink onto pictures and saving the results as a bitmap file, I want to show how this is done in WPF.

In WPF all rendering uses the pipeline - pictures, videos, ink, text, all gets rendered via WPF's 'Media Integration Layer'. As a result, it's very easy and straightforward to combine rendering these different types, both on screen and on a bitmap.

I have attached a WPF sample app that demonstrates how to collect ink on top of an image and then save the combined visual to a bitmap file. In fact, I have used this sample to create the sample picture that is included in my previous post about doing this in Winforms. Here is a screenshot of the sample app (btw, the ink color picker is borrowed from the InkColorPicker SDK sample).

The key class to accomplish our job in WPF is the RenderTargetBitmap class. Here is the relevant code snippet from the sample app:

// render InkCanvas' visual tree to the RenderTargetBitmap

RenderTargetBitmap targetBitmap =

new RenderTargetBitmap((int)inkCanvas1.ActualWidth,

(int)inkCanvas1.ActualHeight,

96d, 96d,

PixelFormats.Default);

targetBitmap.Render(inkCanvas1);

// add the RenderTargetBitmap to a Bitmapencoder

BmpBitmapEncoder encoder = new BmpBitmapEncoder();

encoder.Frames.Add(BitmapFrame.Create(targetBitmap));

// save file to disk

FileStream fs = File.Open(fileName, FileMode.OpenOrCreate);

encoder.Save(fs);

Unlike the Winforms API, there is no behavioral difference between Windows Vista and Windows XP.

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

Annotating Video with Ink using Silverlight

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

Silverlight makes delivering video content in the browser very easy. Silverlight also has ink support built-in. So why not combine these two features to enable some great new scenarios?

I have put together a little sample using Silverlight v1.0 to record and play back ink annotations, synchronized with the video playback. Below is the key piece of XAML markup for this application. We are using an InkPresenter that hosts the MediaElement with the video and takes care of the ink renderering. Also note the empty storyboard here as this is the magic sauce for the synchronized ink playback.

<InkPresenter Name='inkPresenter' Canvas.Left='10' Canvas.Top='10'

MouseLeftButtonDown='onInkPresenterDown'

MouseMove='onInkPresenterMove'

MouseLeftButtonUp='onInkPresenterUp'>

<InkPresenter.Resources>

<Storyboard Duration="0:0:0" Completed="onStrokePlaybackTimerTick"

x:Name="strokePlaybackTimer" />

</InkPresenter.Resources>

<MediaElement Name='mediaElement' Source='bear.wmv'

Width='720' Height='480'

AutoPlay='False' MediaEnded='onMediaEnded'/>

</InkPresenter>

The relevant pieces in the JavaScript code behind the XAML (in file events.js), are the following functions:

ConvertInkToString(strokes) - a function to serialize the point data for the ink strokes into a string for persistence purposes
ConvertStringToInk(serializedStylusPoints) - the reverse function that returns a StrokeCollection for a serialized ink string
onStrokePlaybackTimerTick() - during playback this function is called on every frame; when it is time to play back a stroke, we do so point by point

The full source code is attached to this post. I have also uploaded the sample to the Silverlight Streaming service, so I can pull it directly into my blog here. To check it out, just click the button below to load the sample. Once the video is loaded, you can click the 'Playback' button to replay my pre-recorded ink annotation - or you can click 'Start Recording' to record your own annotations, and then play them back afterwards.

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.

Ink blogging - using Windows Journal and Silverlight Streaming!

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

Are you using Windows Journal to jot down your thoughts on your Tablet PC? Did you ever wish to publish your handwritten notes to your blog?

Here is one way to do this: The TabletPC SDK provides a Journal Reader API that provides access to the content of the .jnt file. Now you can read all content and convert it into a 'blog-friendly' format. Since Silverlight offers great ways to present content in an attractive, interactive way, I decided to write a Journal -> Silverlight converter. The result of this test project is now available as SDK sample on microsoft.com/downloads.

The converter is easy enough to use. Just drop down to a command box and run "JntToSilverlight.exe MyNotes.jnt". This will produce a 'MyNotes' folder that contains the resulting Silverlight application. You can test the results now by double-clicking the 'default.htm' file to load the app into your browser.

OK, now how do I get all this onto my blog? Using Silverlight Streaming, it's very easy: just zip it up, upload it to the service and then stick an IFrame into your blog's HTML. See my previous post on this subject.

To summarize the steps:

1) Create a note in Windows Journal

2) Convert note to Silverlight app

3) Upload to Silverlight Streaming service

4) Insert IFrame into blog

This is still a lot of steps and a bit tedious, but it's a proof of concept. Steps 2-4 all have an API they so are automatable and one could create a tool that does all that in one step.

Here is one example of a converted note on my blog (the original .jnt is attached to this post, if you want to compare). Besides flipping through the pages, you can add more ink, move selected content around and erase ink. Also don't miss the full-screen mode and the mouse-wheel zoom feature!

Fun with Ink & XAML Part4: WPF BitmapEffects applied to Ink

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

Want to create some fancy looking handwritten text or drawing? Tweaking the standard DrawingAttributes on an ink stroke won't get you very far - and creating a custom ink renderer is a lot of work. Why not just apply some of the WPF BitmapEffects to your ink. All you need to do is add a few lines of markup to an <InkPresenter/> and you are done - see markup snippet below (the complete XAML file is attached to his post):

<InkPresenter.BitmapEffect>

<DropShadowBitmapEffect

Color="Black" Direction="20" Opacity="0.8" Noise="0.2" Softness="0.2"

ShadowDepth="{Binding ElementName=shadowSlider,Path=Value}"/>

<BlurBitmapEffect

KernelType='Gaussian'

Radius="{Binding ElementName=blurSlider,Path=Value}"/>

<OuterGlowBitmapEffect

GlowColor="Yellow" Noise="0.5" Opacity="0.5"

GlowSize="{Binding ElementName=glowSlider,Path=Value}"/>

<BevelBitmapEffect

BevelWidth="{Binding ElementName=bevelSlider,Path=Value}"/>

</BitmapEffectGroup>

</InkPresenter.BitmapEffect>

As you can tell from the above markup, I have bound some of the BitmapEffect properties to Slider controls, so you can change their values at runtime to see how it affects the look of your ink. To try it out on your computer, download the attached XAML file and open it in XamlPad (or use Visual Studio to create a WPF application from it).

Now what can you do with this? I think it's a great way to create images of fancy looking, personalized handwritten notes and drawings. You can export the resulting ink to a bitmap file and then use it on your website, in your application or on your blog. Here is some code-behind that takes a snapshot of the InkPresenter and writes it to a .png file:

RenderTargetBitmap target = new RenderTargetBitmap(

(int)inputCanvas.ActualWidth,

(int)inputCanvas.ActualHeight,

96d, 96d, PixelFormats.Default);

target.Render(effectsPresenter);

PngBitmapEncoder encoder = new PngBitmapEncoder();

encoder.Frames.Add(BitmapFrame.Create(target));

FileStream fs = File.Open(@"c:\stuff\InkWithEffects.png",

FileMode.OpenOrCreate);

encoder.Save(fs);

fs.Close();

General note about BitmapEffects: WPF bitmap effects are rendered in software mode. Any object that applies an effect will also be rendered in software. Performance is degraded the most when using Bitmap effects on large visuals or animating properties of a Bitmap effect. WPF bitmap effects do not support partial trust execution, so you cannot load my example code into IE. For more details on BitmapEffects visit this MSDN topic.

Previous post in this series: Fun with Ink & XAML Part3: Ink Data Binding