Blog Archives source threw an exception wpf c#

In general this issue is caused when a referenced resource cannot be found.

<Application x:Class="AppName.App"
                <ResourceDictionary Source="/PresentationFramework.Aero;component/themes/Aero.NormalColor.xaml"/>

In my specific circumstance, as the xaml above details, this issue was caused by a reference to PresentationFramework.Aero DLL that was not contained in the output bin folder of the compiled project. Under references, setting Copy Local to true did the trick for me.



the calling thread cannot access wpf win form c# multi threading

If you receive this error:
The calling thread cannot access this object because a different thread owns it

It is a simple fix to add in some common multi-threading invocation mechanisms.


//with delegate declared
public delegate mydelegate;
this.Dispatcher.Invoke(new mydelegate(funcname));
                    this.Dispatcher.Invoke((mydelegate)delegate() { funcname(); });

//does not require delegate declared, i usually prefer this approach but there are situations for either
                    this.Dispatcher.Invoke((Action)delegate() { funcname(); });
                    this.Dispatcher.Invoke((Action)(()=>{ funcname();}));


this.Invoke(funcname, params);
this.BeginInvoke(funcname, params);


WPF Quick Reference

get window handle

IntPtr windowHandle = new WindowInteropHelper(this).Handle;

bring to front

myWindow.TopMost = true;

common resource dictionaries for skinning (this blog)

wpf get window handle (stackoverflow)
wpf bring to front (stackoverflow)

Common WPF Resource Dictionaries

Skinning a WPF application is as simple as adding an assembly reference (PresentationFramework.Aero) and xml config change. See below.

    <!-- -->
      <ResourceDictionary Source="/PresentationFramework.Aero;component/themes/Aero.NormalColor.xaml"/>

Other sources:

<ResourceDictionary Source="/PresentationFramework.Aero;component/themes/Aero.NormalColor.xaml"/>
<ResourceDictionary Source="/PresentationFramework.Classic;component/themes/Classic.xaml"/>
<ResourceDictionary Source="/PresentationFramework.Royale;component/themes/Royale.NormalColor.xaml"/>
<ResourceDictionary Source="/PresentationFramework.Luna.Homestead;component/themes/Luna.Homestead.xaml"/>
<ResourceDictionary Source="/PresentationFramework.Luna.Metallic;component/themes/Luna.Metallic.xaml"/>
<ResourceDictionary Source="/PresentationFramework.Zune;component/themes/Zune.NormalColor.xaml"/>


Change WPF Toolbar and Window Skin

Took me some Googling to come across some good links to help me find exactly what I was looking to do. Hopefully my post gets enough hits that you’ll come across my title sooner rather than later, and can benefit from my time and research. 🙂

If you’re new to WPF, or even if you’ve been using WPF for some quite some time, you may or may not have noticed that theming and skinning is not relatively straight forward, and there are many different ways to achieve the end result visually.

If you’re using WPF simply to learn the new technology, understand that there are pro’s and con’s to WPF vs standard Winforms, and although the latter is technically “legacy”, depending on third party controls you may or may not be using, implementation in Winforms can be very fast and may still be a better option for some projects.

Here’s a simple grid I’ve come up with to help you decide which to use:

  WinForms WPF
Supports Skins No Yes
Uses graphics resources to render No Yes
Easily bind controls with data No Yes
Easy to design a form with drag+drop Yes No
Some cross-platform compatibility with Mono Yes No
Easily customize look and feel of controls No Yes
Already comes with most controls/visuals needed for business app Yes No

As you can see from the table above, if you are trying to quickly knock out a business app that is not going to require heavy visual modification or too reliant on databinding, it’s probably faster in WinForms. Also, I have personally deployed WinForms cross-platform (Mac, Linux) using mono, which I could not get to work with WPF.

Overall though, for most environments, WPF is usually the way to go if not for visual flexibility then for databinding (why are you using windows client apps again?:P).

One ways listed above that WPF really comes out on top is in utilizing the computer’s graphics card and other graphics resources to render forms. The WPF objects on the screen are still contained in a form however, and many theming examples override the draw methods on the forms themselves which don’t properly utilize the effectiveness of WPF.

In general, I have found there are at least three different ways to change the look and feel of your application in WPF:

Using Silverlight Themes
Using Office Themes
Using your own Custom Themes

If you download and install the Silverlight toolkit (not to be confused with silverlight SDK or silverlight client), you will automatically get multiple dll references which contain XAML themes that can be re-used in WPF. This is a quick way to make your WPF app look good without too much work.

Office themes are pre-built in, and a common choice for many beginner WPF skinners. They share common visuals which you see in many office apps and give your application a more up-to date look and feel with some recognizability by your users also, similar to how Mac applications all share a common theme.

This is also always an option, but be prepared for a long and ardous task and a few lunch days with your favorite designer. Microsoft expressions studio comes with all the tools needed to make your controls as beautiful as you like, and implementing and inheriting from these visuals is actually relatively simple, but when you apply the time it takes to make one control by the amount of different controls you may have, there is alot of work involved. Also for re-usability, you’ll want to put all your custom controls/skins in their own assembly which increases the time even further. If you’re short on time (who isn’t :P), this is not a good option, but in the long-run this could be very beneficial and give your applications their own gleam.

See references for links on how to implement the above and other information regarding skinning and theming in WPF. (The reference links are in order of my google “stream of consciousness” :P)

WPF Skins (this blog), <a href="
MSDN Blog,
Codeproject Article,
Stackoverflow Blog,
Codeplex Article,
WPF Tutorial.Net,
Silverlight.Net Blog,
MSDN Social,
C-sharp Corner Article,
Browsoft Article,
Jan-Cornelius Molnar (Blog),
MSDN Official Blog,

Silverlight Toolkit Default Path

Quick google search turned up nothing for this, so did a little digging on my own.

This path is useful/necessary if you want to manually utilize anything in the toolkit outside of Hilverlight, such as the themes, which are also compatible with WPF.

C:\Program Files\Microsoft SDKs\Silverlight\v4.0\Toolkit

URL Decode in WPF

Crossing from web to forms development you may notice System.Web is not available. You could extract it from the GAC, but would suffer from having to manually update it moving forward.

One solution on the web suggested using Microsoft.XSS library (which is up to version 4.0 at the time of this article).

This would work, but there are some differences in string conversion, especially regarding the “+” and “~” character between using the Web UrlEncode/UrlDecode found in the XSS library or using the Uri method illustrated below.

See references for links to XSS and/or information regarding the differences on how these strings are encoded differently with each method.

Uri videouri = new Uri(AppDomain.CurrentDomain.BaseDirectory + "../../Videos/directory/player.htm");

            string videourl = Uri.UnescapeDataString(videouri.ToString());

            webBrowser1.Navigate(videourl); //can actually accept uri or string

Microsoft Anti-XSS Library 4.0,