September 2010 - Posts
I bring you the sequel for the post found here.
These are just more Silverlight 3 missing features I’ve needed while porting a WPF 3.5 application to Silverlight.
So, without further ado:
Style Setter Doesn’t Support Bindings
Description: in Silverlight 3, a style setter can’t set a value to a binding.
Solution by: David Anson
http://blogs.msdn.com/b/delay/archive/2009/05/07/one-more-platform-difference-more-or-less-tamed-settervaluebindinghelper-makes-silverlight-setters-better.aspx
http://blogs.msdn.com/b/delay/archive/2009/11/02/as-the-platform-evolves-so-do-the-workarounds-better-settervaluebindinghelper-makes-silverlight-setters-better-er.aspx
In a nutshell:
Instead of writing:
<Setter Property="IsSelected" Value="{Binding IsSelected}"/>
Use the code in the post and write:
<Setter Property="common:SetterValueBindingHelper.PropertyBinding">
<Setter.Value>
<common:SetterValueBindingHelper>
<common:SetterValueBindingHelper
Property="IsSelected"
Binding="{Binding IsSelected}"
/>
</common:SetterValueBindingHelper>
</Setter.Value>
</Setter>
The code seems completely different but it is just cosmetics, it works as advertised.
Binding Only Works On FrameworkElement Derived Classes
Description: In Silverlight 3, binding only works on classes that derive from FrameworkElement, where in WPF it works on every DependencyObject.
Solution by: Morten Nielsen
http://www.sharpgis.net/post/2009/05/04/Using-surrogate-binders-in-Silverlight.aspx
In a nutshell:
Instead of writing:
<Image>
<Image.RenderTransform >
<RotateTransform Angle="{Binding Path=Heading}" />
</Image.RenderTransform>
</Image>
Use the code in the post and write:
<Image local:SurrogateBinder.Angle="{Binding Path=Heading}">
<Image.RenderTransform >
<RotateTransform />
</Image.RenderTransform>
</Image>
Template.FindName Doesn’t Exist
Description: Silverlight 3 doesn’t support the FindName function.
Solution by: Bea Stollnitz
http://bea.stollnitz.com/blog/?p=366
In a nutshell:
Instead of writing:
_panel = Template.FindName("PART_PANEL", this) as StackPanel;
Use the code in the post and write:
_panel = TreeHelper.FindDescendent(this, "PART_PANEL") as StackPanel;
Note: Bea has some more excellent tips for porting WPF to SL in this post.
No UniformGrid
Description: Silverlight 3 doesn’t have the UniformGrid control.
Solution by: Jeff Wilcox
http://www.jeff.wilcox.name/2009/01/uniform-grid/
In a nutshell:
Instead of writing:
<UniformGrid Columns="2">
Use the code in the post and write:
<local:UniformGrid Columns="2">
That’s it for now,
Arik Poznanski.
Recently I’ve been working on a port of a WPF 3.5 application into a Silverlight 3 web application. I came across many of the limitation of Silverlight 3 relative to WPF 3.5.
Fortunately, I’ve found numerous excellent solutions throughout the blogosphere.
These have helped me so much I would like to note them for all to see.
Also, this list might come in handy to other people porting applications from WPF to Silverlight.
One final note, the port was done from WPF 3.5 to Silverlight 3. Some of the issues might been solved in Silverlight 4 or have different solutions.
No Commands
Description: Silverlight 3 lacks proper support for commands.
Although Silverlight 3 does have the definition of ICommand, the buttons doesn’t have a Command property to bind with.
Solution by: Patrick Cauldwell
http://www.cauldwell.net/patrick/blog/MVVMBindingToCommandsInSilverlight.aspx
In a nutshell:
Instead of writing:
<Button
Content="Say Hello"
Command="{Binding Path=SayHello}"
/>
Use the code in the post and write:
<Button
Content="Say Hello"
my:ButtonService.Command="{Binding Path=SayHello}"
/>
No ClipToBounds
Description: Silverlight 3 lacks support for ClipToBounds.
Solution by: Colin Eberhardt
http://www.scottlogic.co.uk/blog/colin/2009/05/silverlight-cliptobounds-can-i-clip-it-yes-you-can/
In a nutshell:
Instead of writing:
<Grid
Background="Yellow"
Margin="20,40,-20,20"
ClipToBounds="True"
>
...
</Grid>
Use the code in the post and write:
<Grid
Background="Yellow"
Margin="20,40,-20,20"
util:Clip.ToBounds="True"
>
...
</Grid>
No DataContextChanged Event
Description: Silverlight 3 doesn’t have the DataContextChanged event
Solution by: Emiel Jongerius
http://www.pochet.net/blog/2010/06/16/silverlight-datacontext-changed-event-and-trigger/
In a nutshell:
Instead of writing:
MyControl.DataContextChanged += MyControl_DataContextChanged;
Use the code in the post and write:
DataContextChangedHelper.AddDataContextChangedHandler(MyControl, MyControl_DataContextChanged);
No DataTrigger
Description: Silverlight 3 doesn’t have data triggers, it uses a completely different model, using VisualStateManager
Solution by: Pete Blois
http://blois.us/blog/2009/04/datatrigger-bindings-on-non.html
In a nutshell:
Instead of writing:
<DataTrigger Binding="{Binding IsLoaded}" Value="True">
... DOING STUFF
<DataTrigger>
Use the code in the post and write:
<i:Interaction.Behaviors>
<id:DataStateSwitchBehavior Binding='{Binding IsLoaded}'>
<id:DataStateSwitchCase Value='True' State='Loaded'/>
</id:DataStateSwitchBehavior>
</i:Interaction.Behaviors>
Of course, you should define a state that does the same “STUFF”.
The transition is not immediate, but at least it provide the same functionality as data triggers.
To be continued..
That’s it for now,
Arik Poznanski.
While trying to run the sample project ShellObjectWatcherSampleWPF from the latest version of Windows API Code Pack, I came across the following problem, both in Visual Studio 2008 and 2010:
Or in a search-engine friendly way:
“Cannot create instance of ‘MainWindow’ defined in assembly, ‘ShellObjectWatcherSampleWPF, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null’. Exception has been thrown by the target of an invocation. Error in markup file ‘MainWindow.xaml’ Line 1 Position 9.”
Checking the internal exception, revealed the following:
"Could not load file or assembly 'Microsoft.WindowsAPICodePack.Shell, Version=1.1.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. An attempt was made to load a program with an incorrect format."
Now, when we get an error of “incorrect format” it usually means there is a matching problem between the bitness of the project and the bitness of the machine.
Since my system happens to be x64 based, and the project was compiled as 32bit we got ourselves a problem.
Usually, this doesn’t matter, since .NET is bit-agnostic (yet another advantage of JIT compilation), but since the project depends heavily on P/Invoke, it does indeed make a difference.
The solution is simply to go to the Project Properties | Build and change the Platform target to x64.
That’s it for now,
Arik Poznanski.
Last Tuesday (31.08.2010) Microsoft released a new version for the excellent managed library, Windows API Code Pack.
For those who don’t know, this library serves as a managed wrapper for many Windows APIs which are not included in .NET framework, especially new features from Windows Vista and Windows 7.
I’ve been working with this library for quite some time now and I must say it is “.NET missing piece”. Most of Windows features which doesn’t exists in .NET are at your fingertips =, without handling all the Interop stuff yourself.
With the coming of .NET Framework v4.0 which support side by side execution, we finally can write managed shell extensions without to worry about race conditions between the installed CLRs. And what could be a better starting point for such a shell extension than Windows API Code Pack?
What’s New?
So, what’s new in this release?
Well, the official site says that other than bug fixes, the main new features are:
Shell Object Watcher Preview Handler APIs Thumbnail Handler APIs Let’s try to understand what it means..
Shell Object Watcher
ShellObjectWatcher is a new class in Windows API Code Pack that provides notifications on all elements in the shell, including: files, folders, virtual folders (libraries, search results, network items), etc.
Using this class you can get notifications on: Create, Delete, Rename, Share, Drive Added, etc.
The magic is done using the Win32 API SHChangeNotifyRegister.
The managed API is rather simple and there is a WPF sample application that shows how to get all events of a user selected path:

In the image we see Shell Object Watcher sample application behavior when inserting a USB drive, creating and renaming a folder on C:\ and creating a new text file in the folder.
Shell Extensions
Shell extensions are custom extensions to the Windows operating system, or to be more specific, the shell. Different types of shell extensions extends different parts of the windows shell.
Many parts of the shell can be extended, for example, Windows API Code Pack provides support for the following shell extensions:
- Preview Handlers – lets you customize the way the preview window in Windows Explorer will behave on specific file extensions.
- Thumbnail Handlers – lets you customize the thumbnail of files with a specific file extension.
One thing worth noting is that all shell extensions are usually COM-based components. But using COM Interop we can implement them using the .NET Framework.
The way it usually works is as follows:
- First, you need to write code that adheres to a specific, predefined interface. The interfaces depends on the part of the shell you want to extend.
- Second, you register your object in a specific part of the registry. Different types of shell extensions are registered in different locations of the registry.
- Finally, you use your shell extension by simply going to the part of the shell you have extended and see it in action.
Preview Handler APIs
Preview handler is one type of shell extension. It allows you to customize the preview window in Windows Explorer for a specific file extension.
In the image below we can see on the right a custom preview handler for the file extension xyz2.
In this example the preview handler read the information from the xyz2 file and displays it. Here is the content of the file SampleFile.xyz2:
<?xml version="1.0" encoding="utf-8" ?>
<XyzFile>
<XyzFileProperties>
<Name>Handler Sample File</Name>
<Author>Jon Harkness</Author>
<Rating>45</Rating>
<Region>Seattle, Wa</Region>
</XyzFileProperties>
<EncodedImage>Qk22MQQAAAAAAEYAAAA4AAAAOUAAAAB... </EncodedImage>
<Content>Windows� API Code Pack for Microsoft... </Content>
</XyzFile>
Of course, you can make preview handlers for any file extension, regardless of the file format.
Thumbnail Handler APIs
Thumbnail handler is another type of shell extension. It allows you to customize the thumbnail of a file extension in Windows Explorer.
For example, in the image bellow we can see that the thumbnail of the file SampleFile.xyz2 shows the image that is encoded inside the file.
That’s it for now,
Arik Poznanski.
It has been a year since I’ve started blogging and I think this is a good point for thinking where I was , where I am and where I’m going.
In this year I’ve written 46 posts. Not bad, but not nearly as much as I want or as much ideas I have for posts. Unfortunately, (or fortunately?) I enjoy my work so much that I often find myself practicing it on my spare time, leaving less time for blogging.
The topics I’ve blogged about where mostly Windows 7 related features (over 70%), the rest is divided between WPF and .NET 4 related posts.
On the coming year I hope I can dedicate more time for blogging.
Regarding the topics I’ll write about, I can’t predict the future, so I won’t commit to nothing. That being said, I think what will interest me in the near future is WPF and Silverlight (both for web and Windows Phone), Windows 7 and .NET internals.
I wish you all a happy new (blogging) year.
That’s it for now,
Arik Poznanski.