Archive for the ‘XAML’ Category

I just wanted to point out for those of you who are interested in working with editable FlowDocuments in the Windows Presentation Foundation (WPF) that most standard editing commands such as adjusting alignment, setting various font variations such as underline, italics or bold and also building bulleted lists and other nice (albeit simple) layout tricks, are all available out of the box in WPF.

Say you have a RichTextBox and you want the user to be able to add some text, edit the “style”of this text and also set various style-properties that should be applied to all new text entered into the RTB.

The simplest way to do this is to simply slap a RichTextBox into a grid of a new Window, like so:

<Window x:Class=”EditableRTB.Window1″
Title=”Window1″ Height=”300″ Width=”300″>
<RichTextBox />

(Remember that the contents of a RichTextBox is actually a FlowDocument…)

Now compile and run this, add some text into the box, select it and then press the keyboard shortcut Ctrl+U. You will noticed that the selected text gets underlined. You can try the same for other standard shortcuts available in for example Word Pad, and voila! ;) most of them work right out of the box.

While this is nice it might also be helpful for some users to have buttons to press that invoke the same commands. Sometimes referred to as Usability. The nice thing about implementing such functionality is that it can all be done in XAML. Below is a sample button that invokes the EditingCommands.ToggleUnderline command.

<Button Content=”Un” Command=”EditingCommands.ToggleUnderline”
CommandTarget=”{Binding ElementName=_textArea}”

If we break this down into its interesting parts you will first notice the Command attribute. This attribute takes any RoutedCommand with an associated CommandBinding. In this case we are using a Command that is available by default in WPF. There are many others associated with other types of controls and scenarios such as MediaCommands and ComponentCommands.

The next attribute is called CommandTarget. This is the control on which the Command should be executed. In this sample XAML the CommandTarget is a RichTextBox called “_textArea”.

The last attribute is called CommandParameter. While some default Commands do take parameters, most do not. Thus in most cases you can safely pass a Null value for this parameter.

That’s about it. Granted, the above is slightly simplified, but if you experiment with it for a while you will find how easy it is to manipulate the contents of a FlowDocument in a RichTextBox.

You can easily check the generated XAML of the FlowDocument being generated in the RTB by simply adding another TextBox somewhere in your window, hook up the TextChanged event from the RTB to an eventhandler and have this eventhandler do something like the following:

private void _textArea_TextChanged(object sender, TextChangedEventArgs e)
this.myTextBox.Text = XamlWriter.Save(this._textArea.Document);

This will allow you to see what the different EditingCommands actually do to your FlowDocument in real time :) Be warned though that this is not a very nice solution but only a quick hack :)

Read more about the Editing Commands over at MSDN at this link:



This post is going to explain, in simple terms, how to build an XBAP that needs to access data (in this case XML) over a network. It is also going to talk about how to communicate with a Web Service from within an XBAP. All this while avoiding the WebPermission exception AND the Environment exception. :) And no, we won’t be going full-trust.

As always, some things are simplified for the sake of clarity, if you feel there is something you’d like me to explain in more detail, please drop a comment.

Let’s get to it. First a list of truths (as of 2007/04/12):

  • An XBAP cannot communicate with a WCF Web Service*
  • An XBAP cannot access local resources on the users machine**
  • An XBAP cannot access arbitrary online resources***
  • An XBAP is very sensitive about its Site Of Origin
  • * – As of now, however, rumors say that with the release of .NET 3.5, this might be made possible, within certain security limitations.
  • ** – Unless the application is installed and running with modified security settings. By default an XBAP lives in the security sandbox of the Internet Zone.
  • *** – For example, you can set an Image control to Source an image from an off-site url, but you cannot (by default) access an XML stream from an arbitrary URL, via for example an XmlDocument.Load().

So with that out of the way, how do you go about connecting your XBAP to a webservice? Well it turns out that you can actually communicate to non-WCF webservices, and in the world of .NET that means ASP.NET (asmx) services.

This fact has lead some to suggest the technique of Bridging, but what does that mean? Well, say that you have a set of nice WCF services, or for that matter services that do not reside on the same physical machine / domain as your XBAP. In that case, what you do is you build an ASP.NET service that exposes methods to go get the data from these other services and pass it back down to you, thus acting as a bridge between your XBAP and the rest of the world.

How is this possible if an XBAP cannot access arbitrary online resources? Well it turns out that an XBAP can actually communicate with one and only one point outside its protective little bubble, without security getting in your way so to speak :), and that is that magical place called the Site of Origin. The following illustrations should clarify somewhat:

Xbap data flow

This needs to be explicitly enabled in the security settings for you project.

(In VS2005, right click your project in the Solution Explorer and select Properties, click the Security tab, the Advanced button and then make sure the “Grant the application access to its site of origin.” check-box is checked. Also why you are there, it helps to fill out the “Debug this application as yada yada” textbox with a domain/machine name that makes sense to you. I will explain why later.)

Now that you have that out of the way, two things become possible. First of all you can access webservices hosted on the same site, and even better you can now reference resource-uris that reside on this domain.

So say for example that you have an XML file sitting on the same webserver as the one hosting the XBAP, and you’ve granted the application access to its site of origin. This means you can do the following inside your XBAP:

using System.XML;
	XmlDocument D = new XmlDocument();
	//Do something with your XML...

Not too bad :). Be warned however that the domain/machine name part of the site of origin must be the same as the one you set in the security settings. This can lead to some confusion during debug when for example you might have set the site of origin to ‘http://machinename&#8217; but in your project you might refer to the ‘http://localhost&#8217;. This will not work!

This also means that in some scenarios you can switch out your bridging ASP.NET webservice for a Windows Service that serves up XML data to the webserver that you application can download, thus avoiding the need to open up and secure a web service.

This whole site of origin thing is very important for another reason as well. Say that you are developing and testing an ASP.NET web service on the same machine, and that you deploy it on your local IIS (I’m talking about IIS6 by the way). If you then go ahead and reference that service in your XBAP project, you need to take note so that the url by which you refer to it is the exact same as your site of origin.

Don’t let the machinename/localhost similarity fool you, the Url’s that get added to you Service.wsdl file need to be exactly the same as the ones you specified as the Site of Origin.

Ok, I’ll stop here for now. More on the deployment of ASP.NET services and XBAPs in another post.


Posted on: April 11, 2007

Today I held a 3 hour introduction to building user experiences (that’s UI’s for those who don’t like Buzz words :) using the Microsoft Expression suite of applications.

Focusing mainly on Expression Blend and how to integrate it into the workflow, I took the class from understanding the relationship between code-behind files and XAML, walked through data-binding, control templates & styles, animations and events, and finally built a small RSS reader.

I also gave a short introduction to the .NET framework and how its various parts come together to form the basis of the Expression/Visual Studio workflow.

The whole presentation was in Japanese and I suspect I did some interesting mistakes in both grammar and vocabulary. Sometimes translating technical terms from English to Japanese can be really tricky. A few times I managed to mix the word for Relationship with the one for Jump-Suite, causing some very confused looks :). 


This blog has no clear focus. It has a focus though, it's just not very clear at the moment...

Dev Env.

Visual Studio 2008 Prof / NUnit / Gallio / csUnit / STools (ExactMagic) / doxygen / dxCore / TypeMock / TestDriven.net / SequenceViz / CLRProfiler / Snoop / Reflector / Mole / FxCop / Subversion / TortoiseSVN / SlikSVN / CruiseControl.net / msbuild / nant

Blog Stats

  • 81,617 hits