1. Create a base control as simple c# class and not WPF user control. Derive this base class from UserControl.

    public class ESQBaseControl : UserControl
    {
		#region Constructor
		
        protected ESQBaseControl()
        {
            // protected constructor is required so that derived controls can have default parameterless constructor which is needed for xaml 
            // also protected constructor will ensure that new control creation always use constructor by passing parameters (e.g. in this example passing of string parameter is must in order to construct control)
        }

        public ESQBaseControl(string info)
        {
            
        }
		
		#endregion
		
		#region base implementation
		
		public virtual void SomeOperation()
		{
		
		}

		#endregion
	}

	
	<view:ESQBaseControl x:Class="<namespace>.ESQConcreteControl"
             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" 
             xmlns:d="http://schemas.microsoft.com/expression/blend/2008" 
             xmlns:view="clr-namespace:<namespace in which base control resides>"
             mc:Ignorable="d" 
             d:DesignHeight="300" d:DesignWidth="300">
		<Grid>
			
			<Grid.RowDefinitions>
				<RowDefinition/>
				<RowDefinition/>
			</Grid.RowDefinitions>

			<Label Content="My Control"/>
			<TextBox x:Name="MyTextBox" Grid.Row="1" Text="Some Text"/>
		</Grid>
	</view:ESQBaseControl>

3. Finally, inside the code behind file user control’s concrete logic can be implemented :

	public partial class ESQConcreteControl : ESQBaseControl
    {
        #region Constructor

        public ESQConcreteControl(string info) : base(info)
        {
            InitializeComponent();
        }
        
        #endregion
		
		#region Control implementation
		
		public override void SomeOperation()
		{
			myTextBox.Text = "Hello World!!";
		}
		
		#endregion
	
	}
	

Hosting of WPF user control as content of PropertyPage wasn’t that challenging. In order to host the WPF content inside property page, first HwndSource needs to be configured. In order to create HwndSource, first you need to create HwndSourceParameter. Typical configuration for HwndSourceParameter can be as under :

System::Windows::Interop::HwndSourceParameters^ sourceParams = gcnew System::Windows::Interop::HwndSourceParameters (<Window Name>);

// X position where WPF content to be placed
sourceParams->PositionX = x;
// Y position where WPF content to be placed
sourceParams->PositionY = y;
// height of the WPF content
sourceParams->Height = height;
// width of the WPF content
sourceParams->Width = width;
// Handle for the Parent window inside which WPF content to be hosted
sourceParams->ParentWindow = IntPtr(parent);
// style attributes as needed (“WS_TABSTOP” style needs to be set if WPF content needs to get focus while tabbing
sourceParams->WindowStyle = WS_VISIBLE | WS_CHILD | WS_TABSTOP;

Another important property for HwndSourceParams is “ResetFocusMode”. Default value for this property is “Auto”. Setting this property to “Auto” makes sure that when when the PropertySheet control (in my case) looses the focus and receives focus back the control which had focus prior to loosing focus retains the focus back. If you set this property to “None” then, none of the controls inside the page will have focus when propertysheet control receives the focus.

// now create HwndSource using this parameters
System::Windows::Interop::HwndSource^ hwndSource = gcnew HwndSource(*sourceParams)

Now suppose I have a WPF user control named “PageUserControl” then create instance of this user control.

PageContentUserControl^ pageContent = gcnew PageContentUserControl();
//Now set this user control as RootVisual of HwndSource object. 
hwndSource->RootVisual = pageContent ;

With above code in place it is possible to host the WPF content inside MFC control. This is just basic information which one should know in order to host the WPF content inside MFC container however somewhat plumbing work will be needed depending upon MFC container control in which you are placing the WPF control.

After hosting the control I had one more issue to deal with. My User control developed in WPF had few checkboxes, text boxes, etc. as it’s content. In order to validate my inputs and giving visual indication about the data validation failure, I had implemented interface “IDataErrorInfo”. (Now how this interface is implemented and how it works is not covered in this Post. Google it to find more on it)

When “IDataErrorInfo” interface implemented and bound value to the control is invalid, control will have a red border around it to indicate user about the validation failure. Also, when you set focus on the control like check box through tabbing, you will not be able to see the dotted line around check box when it receives the focus. Following figure shows the focus styles for each case. When User Control is hosted within MFC container, you will assume that “IDataErrorInfo” implementation should work but infect it won’t.

The problem of not being able to see all such decoration is absence of Adorner layer. All these error templates and focus styles etc. are drawn inside the AdornerLayer. The WPF window has an AdornerLayer by default, so we can always see validation errors in WPF. When hosting a user control in MFC, adornerlayer is not available by default and need to add an AdornerLayer into your UserControl to support adorners.

So in order to view all such Focus styles / Error template styles, we need to decorate the UserControl with AdornerDecorator. So following code should do the fix for you :

<UserControl x:Class="TestPjt.TestUC"
             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" 
             xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
             xmlns:local="clr-namespace:TestPjt"
             mc:Ignorable="d" 
             d:DesignHeight="50" d:DesignWidth="300">
    <AdornerDecorator>
        <Grid>
              <TextBox x:Name="txtbox"/>
        </Grid>
    </AdornerDecorator>
</UserControl>

This fix will start showing the expected focus and error template style for each control. HTH!!

1. Implement IDisposable

2. Implement Destructor (Finalize) for object.

This post describes how both gets implemented and what are the pros n cons of both ways.

Destructor & Finalize :

Destructor in managed code can be written in similar way as unmanaged code.

 class TestClass
{
    ~TestClass()  // destructor implementation
    {
        // free resources
    }
}

When destructor is written in managed code, it ultimately translates into following code post compilation :

protected override void Finalize()
{
    try
    {
        // free resources here
    }
    finally
    {
        base.Finalize();
    }
}

(So this means both destructor & Finalize are same in managed context.)

How destructor works :

When reference count becomes zero for the object which implements destructor then that object is marked for collection and object is put into the finalization queue. When garbage collector start collecting the memory, at that time destructor for the objects in the finalization queue will be called. When destructor is called then unmanaged resources can be freed and object memory is collected.

IDispose :

IDispose is basically .net framework interface which defines the method to release the allocated resources. Inside the interface method implementation should be present to release the resources.

How IDispose work :

Let’s consider following code to understand how IDispose and destructor work in tandem. In following example “TestClass” implements IDisposable and also implements destructor. This code uses managed resource StreamReader and unmanaged some Integer pointer which needs to be freed before object is freed after it’s use.

    public class TestClass: IDisposable
    {
        // Pointer to an external unmanaged resource.
        private IntPtr intPointer;
        // managed resource
        System.IO.StreamReader stream;
        // Track whether Dispose has been called.
        private bool disposed = false;

        // The class constructor.
        public TestClass()
        {
            this.intPointer = /* assign some integer pointer*/;
            stream = new System.IO.StreamReader(@"C:\Test.txt");
        }

        // Implement IDisposable.
        public void Dispose()
        {
            Dispose(true);
            // as dispose has already been called supress finalizer
            GC.SuppressFinalize(this);
        }

        private void Dispose(bool disposing)
        {
            if(!this.disposed)
            {
                // If disposing equals true, dispose all managed
                // and unmanaged resources.
                if(disposing)
                {
                    // Dispose managed resources.
                    stream.Close();
                }

                // dispose unmanaged resources here.
                intPointer = IntPtr.Zero;

                // Note disposing has been done.
                disposed = true;

            }
        }

        // destructor
        ~TestClass()
        {
            Dispose(false);
        }
    }

Dispose method with private accessor is being called from both interface Dispose method as well as destructor. When Dispose is called, first managed resource is freed and after that unmanaged resource is freed. Thus both managed and unmanaged resources are freed. After clearing the resources, GC.SupressFinalize is called so that the object is removed from finalize queue.

Now the question is when IDisposable and destructor are doing the same thing then why two separate things are required. Answer of this question lies in the nature of the execution of both these implementation.

Difference between Descturctor-Finalize & IDisposable :

Destructor is not deterministic way of freeing the resource. When object with destructor is marked for garbage collection, it will be put inside the finalization queue. Whenever garbage collector runs, object inside the finalization queue will free the resources. Because time when the garbage collector will run is not sure, it can not be predicted when resources will be freed.

IDisposable is deterministic way of freeing the resource. IDisposable is useful when some shared resources or some high memory consuming resources needs to be freed. Calling the dispose on the object will ensure that resources are freed immediately (however memory associated to the object may not get collected until garbage collector runs).

Some Finer points about Destructor-finalize & IDisposable :

Destructor – Finalize :

1. Finalize is not a good option to use when shared resources / memory consuming resources needs to be freed because of it’s non deterministic nature.
2. Releasing the resources using Finalize is costly from performance point of view. Why implementing Finalize is costly is explained here (last para) in MSDN.
3. In finalize method, finally block has been put and it calls the Finalize on base class also. This makes sure that all the hierarchy of objects release the resources properly.

IDisposeable :

1. As mentioned above, IDispose can only free the resources and can not free the memory consumed by the object itself.
2. Onus of calling Dispose method on the object still remains with the user. Just implementing IDisposable will not make sure that all resources are released properly. Dispose method will not be called automatically by framework except object is called with “using”.
3. Calling dispose is not thread-safe.
4. It is better to consider implementing try..finally block inside the dispose method because if during the execution of dispose method any exception occurs there is no way left to free the resources.

References :

MSDN

“SOLID” is abbreviation formed by collecting initials of five basic designing principles namely,

1. Single Responsibility Principle
2. Open – Closed Principle
3. Liscov Substitution Principle
4. Interface Segregation Principle
5. Dependency Inversion Principle

Let’s try to understand all these principles in brief with some examples :

Single Responsibility Principle :

This principle states that

There should never be more than one reason for class to change.

This principle is simplest however not so simple to apply effectively. Normally while designing the software we are tend to think  in terms of physical grouping and boundaries rather than thinking in terms of responsibility and functionality.

e.g. We have one window in the application which fetches the data from database and displays in the window. Following is the skeleton of the window class :

  public class DisplayWindow
  {
      // establishes connection to database
      public void ConnectDataBase();
      // disconnect connection to database
      public void DisconnectDataBase();
      // gets data from databse
      public void GetData();
      // displays data read from database
      public void DisplayData();
  }

In Above example, all the implementation pertaining to said window has been grouped together in the DisplayWindow class. This  is definitely not following the Single Responsibility Principle. DisplayWindow class in this example is having responsibility of  data retrieval and representation both. There are two problems with this kind of approach :

1. it results in tight coupling between data and representation.

2. All the code has been stuffed in one class only so when changes are made to code it is more prone to regression defects.

If we want to segregate the classes based on the responsibility then it can be done as follow :

So we can make two class namely Window class and DataManger class. Here responsibility of both the classes are very clear. Window class is responsible for displaying data and DataManager is responsible for retrieving data from Database and supplying it to presentation layer. This results in decoupling of data and presentation. Also, such change can make DataManager class reusable.

Hence, when we think about the responsibilities it will result in code which is not so tightly coupled and it will increase the reusability.

Open – Closed Principle

This principle states

Software Entities (Classes, Modules, Functions, etc.) should be open for extension but closed for modifications.

This is very important principle and it states that design the code in such a way so that when the requirement changes, it is possible to meet the requirement by extending the module rather than making changes to existing implementation. It seems like kinda impossible right? However attempt can be made to achieve this objective.

Let’s consider one problem where banking application needs to calculate the interests for various types of account. Following code can meet the requirement :

public class BankApp
  {
      public void CalculateInterest(string accountType)
      {
          switch (accountType)
          {
              case "Savings":
                  // routine to calculate savings account interest
                  break;
              case "Current":
                  // routine to calculate current account interest
                  break;
          }
      }
  }

Now bank introduces new account type i.e. “SavingsPlus”. Implementation has to change to calculate the interest for this new account type to accommodate this new requirement. So in above implementation one new case should be added for new account type. This mean altering the existing implementation every time new account type is introduced. Also, when new account type is added, code has to be changed at all places where action needs to be decided based on the account type. The scenario discussed here is very simple but in real world application altering existing code which is working is definitely risky and can cause regression defects.  Also, one requirement triggering changes at multiple places in already running code is also not desirable. Open-Closed principle is exactly meant for such situation.</p> <p>Consider following solution for above problem :</p> <p><a href=”http://csharpsimplified.files.wordpress.com/2010/10/image1.png”><img style=”display:inline;border-width:0;” title=”image” border=”0″ alt=”image” src=”http://csharpsimplified.files.wordpress.com/2010/10/image_thumb1.png” width=”593″ height=”321″ /></a></p> <p>In above design, Abstraction has been achieved by introducing “Account” base class. Whenever new account type is introduced we can add one more concrete class deriving from “Account” base class and add the interest calculation routine to concrete class. Doing so we don’t have to change the existing implementation at all when new account type is introduced thus making existing code fully closed while code is still extendible.

  public class BankApp
  {
      public void CalculateInterest()
      {
          foreach (Account account in accounts)
          {
              account.CalculateInterest();
          }
      }
  }

Two principles which are key to meet Open-closed principle is Abstraction and Polymorphism. Abstraction helps us in making our code more extensible while polymorphism helps us in making our code close. This is quite apparent from above example.

In real world, no implementation can be 100% closed e.g. if the way interest is calculated is changed then above design is not closed. In order to make change to interest calculation routine we have to change the “CalculateInterest” method of each concrete account classes. However while implementing the calculation routine if some abstraction can be achieved then changes required can be reduced or existing implementation can remain closed when new requirement comes.

Liskov Substitution Principle

This principle state

Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.

This principle stresses on the fact that when sub classing is done, it should not break the base class implementation and subclass – superclass should remain interchangeable. To understand this let’s take following example :

  public class Rectangle
  {
      private double width;
      private double height;

      public Rectangle(double w, double h)
      {
          width = w;
          height = h;
      }

      public virtual void SetHeight(double h)
      {
          height = h;
      }

      public virtual void SetWidth(double w)
      {
          width = w;
      }

      public virtual double GetHeight()
      {
          return height;
      }

      public virtual double GetWidth()
      {
          return width;
      }
  }

  public class Square : Rectangle
  {
      private double size;

      public Square(double s) : base(s,s)
      {
          size = s;
      }

      public override void SetHeight(double h)
      {
          // for square we have to keep both height and width same
          base.SetHeight(h);
          base.SetWidth(h);
      }

      public override void SetWidth(double w)
      {
          // for square we have to keep both height and width same
          base.SetWidth(w);
          base.SetHeight(w);
      }
  }

In above code sample, Class Square is derived from Rectangle. In Square class when SetHeight is called we have to set both height and width in order to keep the sides same for square.

Now consider following use for the above implementation :

  public class EditorApp
  {
      public void ReduceWidthToHalf(Rectangle r)
      {
          r.SetWidth(r.GetWidth() / 2);
      }

      public static void main(string[] args)
      {
          EditorApp editor = new EditorApp();

          Square sq = new Square(20);

          // calling this will result in reduction of both width and height by half.
          // This is not desirable as per implementation of ReducteWidthToHalf method.
          // When actual object passed is Rectangle only width is reduced to half but
          // when Square object is passed, it reduces both height and width by half.

          // this mean both base class and sub class objects exhibit different behaviors
          // and they are not interchangable without breaking functionalities.
          editor.ReduceWidthToHalf(sq);
      }
  }

In above code sample, as my code comment mentions base class and derived class exhibits different behavior and Square can not be substituted for a Rectangle and vice versa.

So in nutshell, Liskov principle states that never break the base class implementation while subclassing.

Interface Segregation Principle

This principle states

Clients should not be forced to depend upon interfaces that they don’t use.

This principle basically talks about the problem of “Polluted”/”Fat” interfaces. Following example (from objectmentor)should clarify what is Fat interface :

There is a door system with normal door operation like door open, close and getting the door status, etc. This is a normal door operation. Basic IDoor interface below should do the needed for this :

However, some specialized door system is requested where door should close / alert user about it being open after certain time period. So this additional feature will require to add some timer function to existing door system as shown in right :

Well, Changing the IDoor interface have it’s implications :

1. Adding new method to existing interface will break the existing implementation because all the classes that derive from the IDoor interface will have to implement newly added method “TimerFunction”.

2. Though not all doors need a timer function, still as per new interface design all the objects that derive from IDoors will have to implement TimerFunction which is not desirable.

Also, adding new features in this way will make interface more n more fat and it will lead to tightly coupled code. Also, making interface fat will result in violation of Open-Close principle.

So solution to this problem is to segregate the Interfaces. Ideal way is to design the separate interface for each client.

So now we have two interfaces as shown in the figure. So to construct simple door we use IDoor interface while constructing TimedDoor we use both IDoor and ITimeFunction interface. In such design, the abstraction has been achieved in IDoor while add-ons have been segregated to new interface. Also, with this design even if changes in ITimeFunction is required than also changes will remain limited only to TimedDoor objects and SimpleDoor objects will remain unaffected. This way the tight coupling which existed in previously design is reduced. Also, after segregation classes are also complying to single responsibility principle.

Dependency Inversion Principle

This principle state

A. High level modules should not depend on low level module. Both should depend on abstraction. Both should depend on Abstraction.

B. Abstraction should not depend on details. Details should depend on Abstraction.

To understand this, consider following Salary Calculator application example where perks for the employee is to be calculated :

Worker is entitled to have various perks. Details of the allowed perk is available inside the Worker class. So in this implementation “ComputePerks” method will iterate through all the perks and go through the if loops to compute the final perk for each employee. But perks entitlement and perks may keep changing i.e. after a while no TransportationPerk is given or new perk say FoodAllownce is added then in this case we will have to change the if loops inside the method to accommodate new structure and this exercise will  repeat every time when perks change. So drawback of this design is :

1. High level module i.e. SalaryCalculator is dependent on the low level classes i.e. various perk calculator classes.

2. Tight coupling exist between the high and low level module.

3. Also, every time low level module changes, High level module has to change which also violates the “Open-Closed” principle.

So to fix this situation we have to follow what this principle is saying i.e. both High and low level module should depend on Abstraction. We should introduce Abstraction layer which can isolate high and low level modules and both can depend on this Abstraction layer. So consider the following new design :

In this design, IPerks interface has been added and now all perks will implement this interface and worker class will use the IPerks. Also, SalaryCalculator class will use the IPerks collection inside the worker class and will calculate the perks by iterating through the list as mentioned in the comment in above diagram. Using this approach,

1. High level SalaryCalculator class is not directly depending upon the Perk classes.

2. Both High and low level classes now depend on the abstraction of IPerks interfaces.

3. Changes in the perk structures i.e. addition or removal of perks will not affect the SalaryCalculator top level class. Every time when perk structure changes only the list inside the worker class will change. So this will also follow the “Open-Close” principle.

So finally, I am done with describing the SOLID principle in brief as per my understanding.  All the principles are very extensive in nature and deserves separate post for each but here it is my humble effort to put them in shortest possible way.  However, people are always welcome to provide their feedbacks/suggestions or pointing out any errors in constructive way.

References :

1. wiki

2. WWW.ObjectMentor.com

3. some other web contents

In my setup, I had no. of text boxes in window whose text property were bound to the property of object in collection. So in this case, source for me was property of the object in collection and target was the text property of textboxes.

I configured my binding object as below :

            Binding binding = new Binding();
            binding.Source = <source object from collection>;
            binding.Path = new PropertyPath(<PropertyName>);
            binding.Mode = BindingMode.TwoWay;
            txtbox.SetBinding(TextBox.TextProperty, binding);

With above binding configuration, source –> target binding worked perfectly for me. But binding from target –> source (i.e. from text box to object’s property in collection) was not working for me. One thing which is important to mention here is, I was changing the text box’s text value in procedural code and not by entering the value in textbox.

It was beyond my understanding why binding was not working? I spent almost half a day trying to figure out this. I googled it but google disappointed me. So I took Adam Nathan’s “WPF Unleashed” book in my hand and started looking for some solution. Again this book came to my rescue. While going through the “Data Binding” chapter in this book, I learned about “UpdateSourceTrigger’ property of the binding object.

“UpdatesourceTrigger” property is very important in “TwoWayBinding” and “OneWayToSource” binding modes. It defines how and when source should get updated.

Value of UpdateSourceTrigger could be any of the value from UpdateSourceTrigger Enumeration. Enumeration values are

1. PropertyChanged – The source is updated whenever the target property value
   changes.
2. LostFocus – The source is updated when target property changes and target object looses focus.
3. Explicit – The source is updated when explicit call is made to update using “BindingExpression.UpdateSource”.

Target controls have default values set for “UpdateSourceTrigger” for binding object. For text box control, default setting for this property is “LostFocus”. In my case, I was updating the textbox (i.e. target) through code and because of that textbox was not loosing focus. Hence my binding was not working. Then I changed above binding configuration to set the UpdateSourceTrigger property of binding object as following :

            Binding binding = new Binding();
            binding.Source = writeItemInfoList[index];
            binding.Path = new PropertyPath("ItemValue");
            binding.Mode = BindingMode.TwoWay;
            binding.UpdateSourceTrigger = UpdateSourceTrigger.PropertyChanged;
            txtbox.SetBinding(TextBox.TextProperty, binding);

And Binding from Target to source started working for me.

The SqlBulkCopy class can be used to write bulk data only to SQL Server tables. However, the data source is not limited to SQL Server; any data source can be used, as long as the data can be loaded to a DataTable instance or read with a IDataReader instance. To copy the source data to destination table in the sql server, need to set destination table name and execute “WriteToServer” method. Following code snippet

// create sqlBulkCopy object
SqlBulkCopy bulkCopy = new SqlBulkCopy(connString);

// set destination table name for sqlBulkcopy object
bulkCopy.DestinationTableName = "[Table Name]";

// write source data to destination sql table
bulkCopy.WriteToServer();

Performancewise using SQLBulkCopy is far better than using normal Insert/Update commands.

            string query = "SELECT Symbol, [Name of Company], FROM [just file name with extension]";
            string connStr = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" + [csv file path without file name] + ";" + "Extended Properties=’text;HDR=YES;’";

            //create dataadapter object
            OleDbDataAdapter adapter = new OleDbDataAdapter(query, connStr);

            // create table
            DataTable dtSymbolDetails = new DataTable("ScriptDetails");
            dtSymbolDetails.Columns.Add("Symbol");
            dtSymbolDetails.Columns.Add("Name of Company");

            // fill the table with data using adapter
            adapter.Fill(dtDetails);

So above code fills up the details of the csv file in the data table for further use.

Also note the text in red above. If column name contains the space then in query the column name should be put between [ ]. I learned it in bit hard way. It shows I’m so poor in my sql knowledge.

Logical resources are of two types :

1) StaticResources
2) DynamicResources

How resources are searched?

StaticResource/DynamicResource markup extension accepts a key name as parameter. So this key is searched while looking up for resource. It is not mandatory that resource has to be defined on the element which is using it. Xaml looks for the resource at the element level first then to parent level and then to application level. Resource markup extension implements the ability to walk the logical tree to find the items upward in the logical tree so if resource is not found, it checks the parent element, its parent and so on until it reaches the root element. At this point, it checks the resources collection at the application level and system level subsequently. If the resource is not found anywhere, it throws “InvalidOperationException”.

Although it is advisable to have unique key associated with resource, however it is not mandatory. While looking up for the resource whatever  resource is found first is assigned.

Static v/s. Dynamic Resources

Defining and Applying Resources from procedural code

At element level adding resources (at definition level, static/dynamic resource is not differentiated) is easy. The syntax is

<element>.Resources.Add(object key, object value);

Static Resource

If in xaml, resources are used as static resource as shown below (provided resource is already defined)

<Button BackGround={StaticResource backgraoundBrush}/>

then from procedural code, this resource can be used as

Button button = new Button();
button.BackGround = (Brush)button.FindResource(“backgroundBrush”);

If “FindResource” fails to find the resource, it throws  “ResourceReferenceKeyNotfoundException”. To avoid this situation, “TryFindResoruce” method can be used which returns ‘null’ if the resource key is not found.

Dynamic Resource

in xaml, dynamic resource can be used as mentioned below :

<Button BackGround={DynamicResource backgraoundBrush}/>

however in procedural code this can be set using SetResourceReference method as shown below :

button.SetResourceReference(Button.BackgroundProperty, “backgroundbrush”);

Do remember that forward reference (i.e. defining the resource before using it) still remains invalid for Static Resource even with procedural code.

Accessing Resources from other assemblies

In many cases resources are defined in separate assembly for the sake of better maintainability. In that case resources can be accessed from different assembly in following way ;

<Button BackGround={DynamicResource {ComponentResourcekey TypeinTargetAssembly=”local:MyResources, ResourceID=backgroundBrush }}

Sometimes the other assembly in which the resource has been defined provides way to access the resource by defining property in class.

public object MyResourceKey

{
      get {return (new ComponentResourcekey (this.GetType(), “backgroundBrush”);}    

}

In such a case, resource can be accessed from xaml in following way :

<Button BackGround=”{DynamicResource {x:static local:MyResourceKey}}”

Accessing System Resources

Sysem Resources i.e. System Fonts, System colors etc. can be used in similar way as mentioned above.

<Button BackGround =”{DynamicResource {x:static SystemColors.Desktopcolor}}”

1) Binary Resources
2) Logical Resources

In this post, I have described the details of the Binary resources.

Binary Resources : Binary resources could be logo/image files, AV files etc. Resource files which are added to project, can have the “Build Action” defined on it from the file properties windows.

Out of the various build actions defined by WPF only following two are important for binary resources :

• Resource : Embeds resource into the assembly (or culture specific satellite assembly)
• Content : this leaves resource as loose file and upon compilation this resource information is not embedded to assembly. Instead, it adds custom attribute to the assembly (AssemblyAssociatedContentFile) which records the existence and relative location of file.It is also possible to access the resource file without adding into the project however with this approach management of resource file becomes bit difficult. However, this approach is useful is resource file is generated dynamically using some runtime information. In such a case, resource file will not be available at compile time so can not be added to project.

What is the difference between the “Resource” and “Embedded Resource” build actions?
“Resource” and “Content” build actions are to access the WPF resources using the Uris. However “Embedded Resource” is for prior technologies. However both options embeds the resource in assembly but “Resource” option to be used for WPF.

URIs for accessing the binary resources

URI	Resource
“Logo.jpg”	embedded in current assembly (using “Resource” as build action) loose resource however physical file is placed along with xaml file or assembly (if selected build action is “Content”)
“A/B/Logo.jpg”	same as above but resource file is located in subfolder “A/B”
“D:\Resource\Logo.jpg”	resource path hard coded
http://pinvoke.net/logo.jpg	loose resource hosted at pinvoke.net website.
ResourceDll;component/Logo.jpg	this URI represents the resource embedded in assembly ResourceDLL.dll or ResourceDLL.exe
ResourceDll;componen/tA/B/Logo.jpg	same as above except resource is located in subfolder
pack://siteOfOrigin:,,,/logo.jpg	resource located at site of origin
pack://siteOfOrigin:,,,/A/B/logo.jpg	resource located at site of origin in sub folder

Site of Origin :

Site of origin at the runtime gets resolved in different ways depending upon the way in which the application has been deployed.

• For a full-trust application installed with Windows Installer, the site of origin is the application’s root folder.
• For a full-trust ClickOnce application, the site of origin is the URL or Universal Naming Convention (UNC) path from which the application was deployed.
• For a partial-trust XAML Browser Application (XBAP) or ClickOnce application, the site of origin is the URL or UNC path that hosts the application.
• For loose XAML pages viewed in Internet Explorer, there is no site of origin. Attempting to use it throws an exception.

Accessing resources from procedural code :

While accessing the resource from procedural code in WPF, triple comma syntax is used however above table for URIs remains still applicable except the last two rows with site of origin.
e.g. to read the embedded resource with “Resource” action “pack://application:,,,/logo.jpg’” can be used.

Following code shows how to read the resource from procedural code :

Image image = new Image();
image.Source = new BitmapImage(new Uri(“pack://application:,,,/logo.jpg”))

There is one more aspect to binary resource and that is localization but I’m not covering it as of now.

The answer is use “System.Environment.GetCommandLineArgs”. Calling this method returns command line arguments at any given point of time.