Comments on: A tip for referencing Assets in your WPF application

By: Steven

Steven — Tue, 13 Jan 2009 15:42:06 +0000

A welcomed extension! If you do not specify the parameter name “Path=” in the XAML, have you seen – and do you know why – VS08 warns that “No constructor for AssetExtension has 1 parameter”? If you include the parameter name “Path=” that warning goes away. Cheers.

By: Yogesh

Yogesh — Tue, 06 Jan 2009 11:22:23 +0000

Thanks for the article Pavan. I was using the direct link approach till now and my application uses a lot of small images. I changed by solution to use resource extensions and I feel this way is a much better and maintainable way of accessing resources.

BTW: Returning a BitmapImage at all places caused exceptions for me (specially in custom controls) so I took Mike’s way by using Binding as the return value and solved the issue. Thanks to Mike for the resolution.

By: Mike Strobel

Mike Strobel — Tue, 06 Jan 2009 06:14:51 +0000

I agree, the custom URI scheme is a really fun exercise. Not only is it cool to have WPF “automagically” recognize your own custom URI format, but it’s also the most lightweight implementation. That is, after all, how pack URIs are handled (see PackWebRequest and PackWebResponse for reference). A custom-tailored implementation should be even more efficient and flexible . You can also register your handler in your App.config file rather than relying solely on a runtime call to WebRequest.RegisterPrefix().

By: Pavan Podila

Pavan Podila — Tue, 06 Jan 2009 00:28:02 +0000

I was thinking of going the route of using Converters but then realized its just unnecessary indirection and I could just save some CPU cycles too .

The Binding option is also interesting. If I may suggest, you should also set the Mode to OneTime, just for good measure.

The suggestions about Caching and WebRequest are the most interesting. I am definitely going to try them out.

By: Mike Strobel

Mike Strobel — Mon, 05 Jan 2009 23:33:21 +0000

A-ha, now I remember how I did it before. I used a Binding inside my markup extension to leverage WPF’s built-in value converters:

public override object ProvideValue(IServiceProvider serviceProvider)
{
var binding = new Binding
{
Source = GetResourceUri(Path),
BindsDirectlyToSource = true
};
return binding.ProvideValue(serviceProvider);
}

By: Mike Strobel

Mike Strobel — Mon, 05 Jan 2009 23:19:32 +0000

Whoops, my example Xaml got stripped out:

[Image Source="{Binding Source='Images/splash.png', Converter={StaticResource ResourcePathConverter}}" /]

By: Mike Strobel

Mike Strobel — Mon, 05 Jan 2009 23:18:26 +0000

Pavan, it seems you’re right about an exception being thrown when you return just the URI. I may have been remembering incorrectly. I think I actually tried a different approach where I used a value converter to convert the “short” path to the fully qualified resource URI, like so:

Obviously, this isn’t much better than typing the full URI, which is why I went on explore other options.

As for the caching, I simply meant that if you are using the same image in multiple places in your application (for example), your extension could cache a weak reference when it creates the first BitmapImage, and then return the same cached instance in subsequent requests for the same image (if the reference is still alive). That would save you some video memory in theory. It’s possible that WPF uses a bitmap caching system internally that I’m unaware of.

By: Pavan Podila

Pavan Podila — Mon, 05 Jan 2009 22:08:02 +0000

That’s a useful thing to have Mike. When using the AssetExtension, I am aware of where it is being used, so the caching part is kind of redundant. Although I love the idea and I may find it useful when returning references of other kinds.

I tried returning the Uri directly but it causes exceptions. That’s the reason why I had to create them myself. I’ll give it a shot again just to confirm.

The WebRequest thing is interesting and would love to try that.

By: Mike Strobel

Mike Strobel — Mon, 05 Jan 2009 20:39:26 +0000

You can actually just return GetResourceUri(Path), and the resulting string will be handled exactly as if you had just typed the entire pack URI in the Xaml. That means image and font URIs will still get properly converted (e.g. WPF will cook up an ImageSource for you if you return a URI to an image file).

The real potential in your solution is that you have the opportunity to do caching. If all of your assets are loaded with this extension, you should consider keeping a lookup table that maps asset paths to weak references of those assets. That way, if they get reused (which many do), you’re not loading them multiple times.

There is another option to consider. You could register a custom web request handler. If create a web request factory that implements IWebRequestCreate, you can register it to handle a custom URI scheme (see WebRequest.RegisterPrefix(…)). Then you could replace your markup extensions with simple URIs, like “asset:///Images/marker/self_fill.png”. You’ll need to implement a custom WebResponse that overrides GetResponseStream(). I ended up doing this for a project where resources were organized in a virtual file system. I needed to check different relative locations in priority order. It worked out rather well.