Hey guys,

Recently I had a requirement in which I had to run an application directly from a DVD. So I made a demo application so that I can share it with you guys.

So first of all we need to create a player inside which the video will play. So add the following code to your xaml file of the window

 

WPF Video APP from CD / DVD

WPF Video APP from CD / DVD

Now we need to add the event handler for these events in our code behind. These can easily be converted to Commands but I did not bother as I wanted to keep it simple. So we add the following code to the code behind of our window.

 

WPF Video APP from CD / DVD

WPF Video APP from CD / DVD

Now we make sure we have the media already present in our application. So we add a Media folder into our application and we add the a video named Lake.wmv to it. And sure it has properties set as shown.

 

WPF Video APP from CD / DVD

WPF Video APP from CD / DVD

Now you can build and run the application.

To run it from the DVD we need to create an ISO file which we can write to a DVD. So create an ISO file I have used Magic ISO Maker which looks something like below.

 

WPF Video APP from CD / DVD

WPF Video APP from CD / DVD

I then browse to the bin folder of my application and drag all the files and folder in it on to the blank area above and create the ISO.

Now we can write this ISO to a DVD or just run it using a virtual drive.

WPF Video APP from CD / DVD

WPF Video APP from CD / DVD

We can browse the DVD and run the application.

 

WPF Video APP from CD / DVD

WPF Video APP from CD / DVD

The source and ISO can be downloaded here.

 

Any questions, comments or feedback is highly appreciated.

Hey guys,

I am sharing my latest application which is a address book developed in WPF and C# using MVVM pattern.

Address Book in WPF C# MVVM

Address Book in WPF C# MVVM

Following are the features of the application.

  1. You can save data to the data base local to application. None of the other applications are required.
  2. Functionality to import or export excel database
  3. Needs only .NET Framework to run.

You can download the Source code and the executeable below.

Download

Feel free post any questions, comments or feedback.

 

Hey Guys,

A couple of times a faced an issue while working on code. I wanted to check which files I edited since yesterday or since a specific date as in a folder, so i developed an application which which will find the modified files in the selected folder after the specified date and time.

 

Below you can find the installer. Source Code and Executeable for the

 

Download the source code for ModifiedFilesFinder 1.0 @OneDrive or @Google Drive
Download the installer for ModifiedFilesFinder 1.0 @OneDrive or @Google Drive

To run the application you need to download the files above.

  • Go to the folder
ModifiedFilesFinder 1.0

ModifiedFilesFinder 1.0

  • Run the Setup.exe
ModifiedFilesFinder 1.0

ModifiedFilesFinder 1.0

  • Click on install and after the installtion completes the application will open.
ModifiedFilesFinder 1.0

ModifiedFilesFinder 1.0

 

ModifiedFilesFinder 1.0

ModifiedFilesFinder 1.0

  • Once the application scans the selected folder it will prompt you to select the location for the text files which has th elist of all the modified files.
ModifiedFilesFinder 1.0

ModifiedFilesFinder 1.0

  • To remove the application you need to uninstall the application form control Panel. So go to Uninstall programs and find the program by name FindModifiedFiles and uninstall it.
ModifiedFilesFinder 1.0

ModifiedFilesFinder 1.0

 

Any feedback, comments or questions are most welcomw.

 

WPF being a fairly new technology might need to communicate with the components that are made in other technologies so in this section we will have a look as to how we can communicate with other systems that are built in Windows Forms or Activex.

Mixed UI Technologies

So if our WPF application needs to use controls that were developed earlier or just merely in different technology or we need to integrate with legacy plug ins or maybe there is some stuff which is available in WPF or we are moving our application to WPF but module by module. In all these cases our application will be hybrid of WPF and other applications.

WPF and HWNDs

The only major issue in WPF is that WPF is designed differently from Win32. The major difference is in the composition of the Window i.e how different elements combine to form a Window. In a classic Win32 app the composition works by partitioning the window into different elements. It UI elements gets the ownership of the window. This portioning is tied to the Window Handle or HWND. HWND is the type that represents Window handle in User 32. So each Win32 control has its own HWND owns all the pixels in some region of the screen, whereas in WPF the composition works in different way. WPF treats the entire window as one big canvas and all the components get to paint on that. So the individual WPF components don’t get to won a region individually. SO WPF creates just one HWND to fill the entire window. If we run the tool designed to explore the window handle then we can see that WPF window has one HWND.

As you see in the image below I have run Microsoft Spy++ and as you could see the WPFInteropSample application has a HWND wrapper. So we can see that WPF has just one big HWND for the application. However Pop ups have their own HWND as they are separate top level windows.

 

WPF and HWNDs

WPF and HWNDs

Interop Not Free

You might think that using the existing components might be cheaper but that’s not the case with interop in the long run.

  • The development cost if more as you are using a mixture of technologies.
  • There might be design compromises due the limitation of using multiple technologies in application.
  • During the runtime the application memory usage will increase by using both Windows Forms and WPF in one application.
  • There can CPU costs as well.
  • Also the WPF and Winforms control only almost look alike and the difference becomes more obvious

So we should use hybrid applications with discretion.

Limitations of Interop

When WPF was being designed it was not planned to be run on older version of windows bu after lot a demand Microsoft changed that and made it available to run on Windows Server 2003 and Windows XP which was great. But to get this accomplished there were changes that were made and those led to a few limitations. The major issues are as below:

Airspace issue

This is the major issue. Just like two aircrafts cannot occupy the same airspace similarly two different technologies cannot occupy the same pixel space. The WPF window needs to partitioned so that each area can be used by WPF, Win32 or Directx. We cannot have more than one technologies rendering on the same pixel.

The directx limitation might seem strange as we know that WPF uses directx but the reason is that WPF does not want to share its directx services. In .NET 3.5 SP1 we can take the output of directx and use it as a brush in WPF. So it is possible to get the directx output into a region of the window. But still the control is with WPF and the HWND control handled by WPF

Example

Transforms

The transforms applied in WPF will not apply to other technologies even though the component of other technology may be a child of WPF content.

Events

Event bubbling does not work across technology boundaries either.

Multi-level hybrid Nesting

There are limitations on how deeply we can nest the content. We cannot host a Windows Forms Controls inside a WPF Control  that is hosted inside a Windows forms controls that is the child of the WPF window.

Airspace Issues in WPF

  • Clipping
  • Z-Order
  • Animated Objects
  • Opacity
  • Pseudo Transparency

Multiple Top Level Windows

A simple solution to all the airspace problem is to use multiple top level windows as all the airspace issues occur when Win32 and WPF components share the same window. Airspace limitations do not apply to the desktop level. So a simple solution to the Z-order problem is to put all the content that needs to go on top in a different window. This is the same way in which pop up works. It shows up on top of all the other windows and content. We can make use of layered windows introduced by windows 2000 as after that it has been possible for multiple windows to share pixel screen. Also the WPF application can make use of transparent windows (Window.AllowsTransparency).

Input Differences

Another issue in WPF interop is handling the user input as event bubbling and tunneling is tied into WPF visual tree. So if the mouse goes into the other technology elements then events won’t bubble out of it. So the properties like IsMouseOver, IsFocusWithin, etc will not return what we are looking for.

Interop Combinations

The following table show how easy or difficult the various Interop combinations are. The easiest interop to do is with Windows forms. It is slightly harder to interop with Win32 components because we are dealing with C++ code. Hosting an activeX control inside WPF is easy but vice versa is difficult. If we want to host WPF content inside HTML then it’s easy but user restrictions are applied to WPF xbap inside the browser.

Technology WPF   Inside WPF   Outside
Windows   Forms Easy Easy
Win32 Fairly Easy Fairly Easy
ActiveX Hard Easy
HTML Easy (With Limitations) Easy

 

WPF in Win32

The most important thing to do is to host the WPF content inside the Win32 because without this we would not be able to display the WPF content at all. This service is provided by the HwndSource class as it connects the WPF visual tree to an Hwnd. We can do this as shown in the code below. We just need to pass the parameters inside the constructor and then set the WPF visual tree as the root visual.

 

WPF in Win32

WPF in Win32

All the WPF content uses an HwndSource and we can retrieve this by the following code. We can get hold of the Hwdn in which the WPF content is displayed and this is useful as Win32 components require us to know Hwnd.

 

WPF in Win32

WPF in Win32

Win32 in WPF

To host the Win32 content inside the WPF we can use HwnHost and derive from it. Then overriding the methods to create, destroy window and for handling its windows messages.

 

Win32 in WPF

Win32 in WPF

HwndHost Keyboard Handling

HwndHost host has some optional overrides for dealing with keyboard inputs. If we want the keyboard accelerators to work perfectly whether inside WPF content or Win32 content then we need to override these methods.

  • TranslateAccelerator
  • TabInto
  • OnMnemonic

Message Pumps

If we are hosting WPF content in a Win32 application then we need to modify the Message Loop to provide the WPF Dispatcher with the opportunity it needs to manage the window messages. The Class ComponenetDispatcher that offers various static methods that we should call for message handling when a message arrives or when it’s going idle. Also WPF needs to know when you have entered the model state so that WPF can stop responding to UI inputs.

Note that we don’t need to do this when we are integrating Windows forms and WPF. WPF and Windows Forms collaborate to provide our application with message handling.

WPF inside Windows Forms

In the code below we can see WPF content inside a Windows Forms container. There is a class called ElementHost that derives from WindowsFormsControl class so that we can edit any windows forms user interface. Buts cild property is of type FramworkElement that allows us to host any WPF element.

Create a WPF Control Library and add the following code to the UserControl.

 

WPF inside Windows Forms

WPF inside Windows Forms

Now add a Windows Forms application to the solution and refer this control library in that project.

 

WPF inside Windows Forms

WPF inside Windows Forms

When we select the main form we see that theUserControl1 is available for us to use.

 

WPF inside Windows Forms

WPF inside Windows Forms

Just drag it on to the windows form and run the application and we can see the WPF control inside the Windows Forms application.

 

WPF inside Windows Forms

WPF inside Windows Forms

Windows Form inside WPF

Hosting Windows forms content inside a WPF application is almost identical. Instead of ElementHost we have WindowsFormsHost and this derives from framework element and we can add it to any WPF UI and its child property accepts a Windows Forms Control.

 

Windows Form inside WPF

Windows Form inside WPF

Windows Forms and Layout

While using the ElementHost or WindowFormsHost WPF does its best to bridge between the two layout engines and overall it works fine (Docking, Anchoring and Auto-Sizing). Even the scaling transform works for WindowsForm inside WPF.

Ambient Property in Windows Forms

These are like WPF inherited properties. Windows forms uses these to make sure that the foreground color, background color and mouse cursor are propagated to child controls.

WindowsFormHost and ElementHost both have a PropertyMap which they use to manage the transition back and forth between the inherited properties and Ambient properties and it works fine most of times.

If want to modify this then we can register a callback that will be called while propagation of any property across the interop boundary.

 

Any questions, comments or feedback are most welcome.

The code for this post can be found here.

 

In this section look into multithreading in WPF and how we can send long running task to a different thread than the UI thread. We will look at how the threading model of WPF works. We will also look into how we can load data in a different long running thread and then utilize that data through data binding. Also we will see how we can communicate with WCF from WPF.

WPF Threading Model

Responsive UI and Distributed Systems

In our application if we are dealing with data which is coming from remote system then we cannot deny the fact there can be network delays because of various reasons (Network congestion, Busy Servers, Packet Loss, higher round trip times, etc) and that could render our UI unresponsive. Other reasons for UI unresponsiveness could be long running IO tasks or slow CPU. So we should take care of this while designing the application and make sure the UI does not freeze in such conditions.

Dispatcher

The WPF threading model revolves around an object called as dispatcher. It can be considered as the object that owns the message loop for a particular thread. In any windows application all the mouse and keyboard inputs are sent via message sent to the thread associated with the target window. In WPF receives these messages and decides what to do with them. All WPF elements are associated with the Dispatcher. We can see this in the DispatcherObject base class. This is the base of DependencyObject which is root of WPF class hierarchy.

WPF Dispatcher

WPF Dispatcher

As we have seen that DependencyObject object is the base class for most WPF types and it in turn derives from DispatcherObject which derives from System.Object, the base class for all .NET objects. The DispatcherObject provides access to the object to which the Dispatcher is associated and it provides functions to check whether we are on the right thread or not. The Dispatcher is always associated with a particular thread and in most cases we need to be on that thread when we make any changes to the object on that thread. WPF makes use of these methods to make sure we are performing operations on the right thread.

  • CheckAccess – This will return false if we are on the wrong thread.
  • VerifyAccess – This will throw an exception if we are on the wrong thread.

So this is in accordance with STA model. The reason why WPF uses this model is to work with COM based API’s like clipboard, etc.

However it is technically possible for an application to have multiple dispatchers each on a different thread but each top level window needs to be on a single dispatcher. However its very common to have only one dispatcher for one WPF application. And also generally a WPF application has one UI thread but that’s not a constraint. So we cannot modify anything on the UI elements from the wrong thread means non UI thread directly. As all the user inputs are handled by the dispatcher so when we do any other task on that thread then the dispatcher will not be to handle the user input. So we should not block the UI thread to the functions that take long time to complete.

So how do we follow both the things I just said above because one says do all the work on UI thread to avoid exceptions and the second one says do no work on UI so that the UI is responsive.

Async Work

The answer is to perform slow work asynchronously either by using multithreading or some API’s. If we want to update the UI in between these tasks then we can use the Dispatcher to come back on the right thread for updating the UI. We can do this by calling the Dispatcher.BeginInvoke method and passing the method delegate to it. This will end up as a message in the message queue of the dispatcher and when the dispatcher processes this message in its queue it will invoke the specified method and make eth updates to the UI thread. This will make sure that the UI updates will happen always on the right thread no matter what thread we are on.

We can see how to do this in the image below. We have some slow work to do. As you can see this work has been put in an anonymous delegate and this is invoked by a thread in a thread pool. So we have delegated the slow work to some other thread so that the UI is responsive and when the slow work is completed and the UI needs to be updated then we have called Dispather.BeginInvoke to our UI update.

Let’s see this action. Add a class in with the following code in your application to do the time consuming task.

 

WPF Async Work

WPF Async Work

Now add the following code to the xaml of the application.

 

WPF Async Work

WPF Async Work

Add the following code to the code behind.

 

WPF Async Work

WPF Async Work

When we run this code we will notice that during the time our time consuming task runs the ui is responsive and if we have a look at the Thread ids we will notice that we ran the Time consuming task on a different thread then the other tasks and in the end we used Dispatcher object to Update the UI.

 

WPF Async Work

WPF Async Work

Dispatcher Priorities

As we have seen the previous section that we specified DispatcherPriority.Normal in the Dispathcer.BeginInvoke method. The different dispatcher priorities are as below and these are increasing order of priority. For example the DataBinding has higher priority than rendering. This is how it should be. Say we have an application that databinds all the elements on a page and suppose the data binding for all the elements is updated then we do not want call render for each element separately. So we just get one painting of the UI.

  • System Idle
  • Application Idle
  • Context Idle
  • Background
  • Input
  • Loaded
  • Render
  • DataBind
  • Normal
  • Send

DispatcherOperation

This is returned by Dispatcher.BeginInvoke and can be used to track the progress of the work.

  • Status Property – It has the status property which tells us whether the operation is still pending in the queue or executing or finished or aborted.
  • Result Property – It also has a result property that can be used to get the outcome of the operation if there was any.
  • Priority Property – The objects also provide access to the operations priority as well.
  • Completed Event – Called when the operation completes.
  • Aborted Event – Called when the operation aborts.
  • Wait Operation – This method block until the operation completes and if the operation has already completed before we have called wait then wait returns immediately. You need to be cautious while using Wait because you are blocking the worker thread till the UI operation is completed and this might lead to a deadlock as the UI thread might be waiting for the Worker thread to finish up.
  • Abort Operation – This operation aborts the operation if the operation is still waiting in the queue. If the operation has already started or finished the Abort does nothing.

Synchronization Context

Instead of using the Dispatcher.BeginInvoke we can use the SynchronizationContext.Post method to make the updates to the UI. This was introduced in the version 2.0 of .NET and also works for Windows Forms and ASP.NET. A dummy implementation for this is shown in below.

 

Asynchronous Options

Let’s have a look at the various asynchronous options available with .NET.

.NET v 1 asynchronous pattern

Whenever we see two methods, one called Begin___ and the other called End___ we know that we are using .NET v1 Async pattern. The Begin___ method needs to return result of type IAsyncResult and should also allow you pass a Callback function that will notify the completion of the method. The types that support this pattern are as below:

  • All delegates support this pattern
  • All networking classes implement it
  • All web service proxy classes implement this including WCF

The major advantage of using this pattern is that we gain a lot on the efficiency of the pattern. Just like the concurrent threads work in the Windows Operating system, the same the way this implementation needs the CPU time at the start and end of the operation explicitly and the remaining work is done concurrently. Like if it’s an IO task then it’s handled asynchronously by specialized hardware. So the major advantage of this pattern is its efficiency and we manage thousands of network operations with a few threads.

But this might not be very useful for a WPF application as the main use of threading in a WPF application if just maintain the responsiveness of the UI.

.NET v2.0 event-based asynchronous pattern

This pattern was introduced with .NET 2.0 and is more suited for user interface development.

In this pattern we will find methods of type ___Async and CancelAsync or ___AsyncCancel. So this pattern supports cancellation in scenarios where it can be done.

Another feature that we see in this pattern is that an event will fire when the operation completes and also when the progress of the task is changed.

And the most important thing to notice is that these events are raised on the user interface threads. This is a mandatory requirement for the components implementing this pattern. This is generally done by SyncronizationContext or AsyncOperationManager to make sure the events are raised on the thread on which the operation was invoked.

The advantages of this pattern are that it offers cancellation and is simple to use. The major advantage of this pattern is that presents a Single threaded API for multithreaded operations. So when are using a component that implements this pattern we don’t see anything other than the dispatcher thread for Async operations. So we call the Async work from the UI thread and we get the completed notifications back on the UI thread.

We have seen an example of this implementation in the Printing section. The XPSDocumentWriter offers the WriteAsync and CancelAsync methods.

So this method seems perfect for WPF but the couple of cons for this pattern are that it is not widely supported and it does not support the WaitHandle available in the V1 Pattern.

Thread Pool

Some components offer nothing but a synchronous blocking API. We saw this in the section where I showed you the TimeConsumingTask. So we need to go and manage the blocking and unblocking of the thread.

We could use a Thread Pool for it. .NET always provides pool of thread to do random work on random threads. .NET dynamically creates and destroys thread to meets the applications workload and this is really helpful in synchronizing the unhelpful synchronous components. You should remember that anytime we are using a delegate asynchronously we are using the thread pool internally.

The V1 and V2 of .NET asynchronous also use the thread pool in some implementations like the background worker class.

The only problem in working with thread pool is to get back to the UI thread when the work is done.

Create your own thread

Finally the last option is create our own worker thread. The major advantage of creating your thread is to have less concurrency. Yes it’s an advantage in terms of WPF because the only reason for asynchronous work is to ensure the responsiveness of the WPF UI.

The best way to go for a WPF application is to have one worker thread and one UI thread. And having only 2 threads will simplify the concurrency issues as we know what work is being done on what thread.

The only disadvantage with this is that there is no direct support for this approach in .NET library so we have built up our own mechanism to pass the messages between the worker thread and the UI thread. It’s not a lot of work as we just need a queue and some synchronization. But we should not be hesitant for the approach a little work upfront will give a lot of flexibility.

Databinding and Threading

In the previous sections we have seen how we can update the UI coming back from the worker thread. Now we will see how we can update the UI if we are using data binding. This is useful in the cases our data source is producing the change notifications. Add the following class and code to you application. This class will provide datasource which provides slow data. As we can see in the code the get accessor is fast but the set accessor is fetching the updates. The FetchNewData method simulates the slow operation. We are using the thread pool to get the work done and then we are sleeping on the thread for 5 seconds and then the property is updated. Also you can see that this class implements the INotifyPropertyChange to implement the change notifications.

 

WPF Databinding and Threading

WPF Databinding and Threading

This is used as the source for the UI as we can see in the code below. This source becomes the DataContext of the Window.

 

WPF Databinding and Threading

WPF Databinding and Threading

And we go to the xaml we will see that the textblock’s text property is bound to the data property of the DataContext.

 

WPF Databinding and Threading

WPF Databinding and Threading

WPF will take care of this as you can see by running the application.

 

WPF Databinding and Threading

WPF Databinding and Threading

However this is supported only in case of properties for the current version of WPF. If we are using a list and using data binding on the list with multithreading then we will get an error. So WPF actually offers only partial support for Async updates. Maybe the future versions might offer it as currently WPF does not offer a CollectionView that support changes to its collection from a thread different from a dispatcher thread.

We can change our approach to get this done. For example we can create our ObjectDataProvider (ObjectDataProvider.IsAsychronous) on the worker thread instead of the UI thread. And we can also set the binding on a particular element to be Async (Binding.IsAync).

I do not recommend this approach because xaml is not the place to handle the threading issues. So we are usually better off handling these issues in the DataSource.

WCF and WPF

WCF and v1 Async Pattern

If we are using WCF along with WPF then we can use the Async proxy class generated by WCF to perform work asynchronously. This can be done in two ways

  • While generating the Async class via command line we can affix /async at the last of the svcutil.exe command
  • Or in Visual studio while adding the service reference we can configure it work Async.

This setting will make the generated proxy to implement the .NET v1 Async pattern. This does not require any implementation form the server as this is just the way we want WCF to present the proxy.

WCF and DataBinding

WCF also offers some help for the databinding as well. The svcutil has the option which will implement the INotifyPropertyChange on the types generated form the schema.

This is useful when the WPF application using a simple visual layout only directly over WCF service.

 

Any questions, comments or feedback are most important.

The code for this post can be found here.