DCSIMG
September 2010 - Posts - Arik Poznanski's Blog

Arik Poznanski's Blog

It CAN be done with .NET

News

MVP

MCC

CodeProject MVP

MCPD

MCTS

Subscribe to my blog by email

Arik Poznanski LinkedIn Profile

Email: arik.com at gmail dot com
or, use this form

Locations of visitors to this page


Sela Group

Sela Canada

DZone MVB

Links

Official Blogs

WPF / SL Blogs

Developers Blogs

September 2010 - Posts

Porting from WPF to Silverlight: The Missing Pieces, Part 2

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.

Porting from WPF to Silverlight: The Missing Pieces, Part 1

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.

Fix Error: An attempt was made to load a program with an incorrect format

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:

image
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.

image

That’s it for now,
Arik Poznanski.

Windows API Code Pack v1.1 Released!

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:

    image

    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.

    image

    That’s it for now,
    Arik Poznanski.

  • Happy Blog Day #1

    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.

    image

    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.

    Posted: Sep 09 2010, 02:01 AM by arik |
    תגים:,