WPF Introduction

WPF is short for Windows Presentation Foundation. Microsoft takes it as a next-generation presentation system for building Windows client applications with visually stunning user experiences. Obviously, the “next” is compared with MFC; a presentation system for windows before WPF. WPF brings in many new features for developers.

1)      DirectX instead of GDI/GDI+/user32

To achieve a visually stunning UI efficiently, WPF uses DirectX as its graphic engine instead of GDI/GDI+/User32. The difference between them is that DirectX has hardware acceleration while GDI/GDI+/User32 does not. That means that DirectX can use the GPU to do part of the rendering work while GDI/GDI+/User32 can only use the CPU to complete entire rendering work. When dealing with complex textures, special effects such as partial transparency, anti-aliasing, and three-dimensional graphics, a GPU is much faster than a CPU. Indeed, DirectX is designed as a game developer’s toolkit and is supported by all the modern video cards, so a WPF application can easily implement excellent graphics effects similar to those used in games. But in some cases, such as when the DirectX version level is lower than 9, a WPF application doesn’t have hardware acceleration. Open the site http://msdn.microsoft.com/en-US/eng/library/ms742196(v=vs.110).aspx  for all the cases.

WPF Graphic Engine

2)      Data-Driven

In old presentation systems such as MFC, data is used by the UI. When a datum is modified, the UI doesn’t update until a refresh function is called. On the contrary, WPF is a data-driven system. The change of a datum would cause the UI to refresh automatically if the datum is a Dependency Property and AffectsArrange is true. Also, the change of UI would cause the change of data automatically if there is a two-way binding between them.

 WPF Data Driven

3)      Resolution Independence

Traditional windows applications are bound by certain assumptions about resolution. Developers usually assume a standard monitor resolution (such as 1366 x 768 pixels), and design the window in mind and try to ensure reasonable resizing behavior for smaller and larger dimensions. The problem is that the application isn’t scalable. As a result, when the application runs on a monitor with higher resolution, the application window will be smaller and more difficult to read. While with lower resolution, the window for the application will be larger and therefore part of the windows will be displayed off-screen [2].

WPF uses device-independent units to measure Windows and other elements, it bases its scaling on the system DPI setting. A unit is defined as 1/96 of an inch. The physical size (the real size when it’s displayed on the monitor) of a unit is calculated as

[Physical Unit Size] = [Device-Independent Unit Size] x [System DPI]

= 1/96 x System DPI (pixels)

= 1/96 x System DPI / Screen DPI (inch)

According to the definition of the unit and calculation of physical unit size, 96 units make up to an inch based on system DPI. But the physical size may not equal to an inch unless System DPI is equal to Screen DPI. To have a comfortable view of the windows, System DPI is always set closely to Screen DPI. So when running on a higher resolution monitor, System DPI is larger and a WPF window keeps its size by rendering it greater detail with more pixels. And a WPF window keeps its size by rendering it with less pixels when the monitor’s resolution is lower.

Note:

1. System DPI: It can be set by Personalize->Display->Smaller-100% (96dpi)/Medium-125% (120dpi)/Larger-150% (144dpi).

2. Screen DPI: A 19-inch LCD monitor with a maximum resolution of 1600 by 1200 pixels. The screen DPI of the LCD monitor is

WPF Resolution Dependency

4)      Declarative User Interface

Except for the traditional ways  of designing user interfaces, such as drag and drop control, and code (C#/C++/other languages), WPF provides another way by using declarative markup language XAML. XAML is very easy and convenient just like HTML. What’s more, it allows the designers and developers to work simultaneously, since the design file (.xaml file) and the code file (.xaml.cs file) are two separate files.

WPF XAML

5)      Style, Resource and Template

WPF provides Style, Resource and Template to modify the appearance of a control. It’s so flexible that developers can get whatever effects they want. What’s more, Style, Resource and Template can be written in a standalone file, so that they can be reused.

6)      Routed Event

In traditional windows application, an event is only raised on the control that gets focus. While in WPF, almost all the UI events are routed events. Routed events can depart into Direct Event, Bubble Event and Tunnel Event according to their routing strategy. A Direct Event behaviors like a traditional event. A Bubble Event is raised from the original source (the control focused) to the outermost parent and a Tunnel Event is raised in the opposite direction. Developers can easily stop the routing process by set e.Handled (e is the EventArgs) true. So developers can easily handle or stop one event in any control along the routing path. It’s very useful in many cases, for example setting a global event.

WPF Routed Event

7)      Command

This is a small feature in WPF. In brief, if there are several events that can be used to perform the same function, such as mouse click, shortcut key and menu, developers can bind the events to one command that performs the function instead of writing an event handle for each event.

WPF Command

8)      Multimedia and Annotation

WPF provides high-level APIs for using multimedia and annotation, such as audio and video. Developers can easily deal with multimedia and annotation with them and design a wonderful rich application.

Reference:

[1]MSDN:http://msdn.microsoft.com/en-us/library/ms754130(v=vs.110).aspx

[2]Pro WPF 4.5 in C#: Windows Presentation Foundation in .NET 4.5, written by

Matthew MacDonald

How to Get the Working Directory in a WPF Project

Yesterday, my colleague told me that there was a weird issue that existed in our WPF sample code for Dynamic .NET TWAIN. What we wanted to implement was to create two projects, and start one application from another. The problem was, when we started the invoked application independently, it worked well. Whereas when it was invoked from another application, none of the UI resources loaded.

ImageBrush dpTitle.Background = new ImageBrush(new BitmapImage(new Uri(imageDirectory + "title.png", UriKind.RelativeOrAbsolute))); // Loading UI resources

Because of this behavior, I thought the resource path might be wrong. After I investigated the source code, I found that our developer used the Property Environment.CurrentDirectory.

Here is the code:

String imageDirectory = Environment.CurrentDirectory.Substring(0, Environment.CurrentDirectory.IndexOf("Samples")) + @"Samples\Bin\Images\WpfDemoImages\";

Refering to Microsoft’s remarks “By definition, if this process starts in the root directory of a local or network drive, the value of this property is the drive name followed by a trailing slash (for example, “C:\”). If this process starts in a subdirectory, the value of this property is the drive and subdirectory path, without a trailing slash (for example, “C:\mySubDirectory”)”, using this property seems to be completely correct.

To verify this issue, I decided to check the directory output in the two different cases.

The output directory for running the app independently:

C:\Users\admin\Desktop\HTTP_Directory\Dynamic .NET TWAIN 5.0 Trial\Samples\Bin\Images\WpfDemoImages\

Start the app from another app:

Process.Start(@"C:\Users\admin\Desktop\HTTP_Directory\Dynamic .NET TWAIN 5.0 Trial\Samples\C# Samples\VS 08\WpfControlsDemo\WpfControlsDemo\bin\Debug\WpfControlsDemo.exe");

Output directory:

C:\Users\admin\Desktop\HTTP_Directory\WPF TEst\WPF TEst\bin\Debug

As you can see, the two result are different. The second output directory is the working directory of the caller application. In this situation, the Property Environment.CurrentDirectory cannot return the expected result.

Is there an alternative? As a matter of fact, Microsoft provides another method. Here is what I found:

String strAssemblyPath = System.Reflection.Assembly.GetExecutingAssembly().Location;
String imageDirectory = strAssemblyPath.Substring(0, strAssemblyPath.IndexOf("Samples")) + @"Samples\Bin\Images\WpfDemoImages\";

This method returns the location of the loaded executable file. Therefore, we can easily find out the relative path of the resource files. Now, our WPF projects can work perfectly.

Using Barcode as Batch Separator in Web Application

For document management, it is a common requirement that a user puts a stack of documents for automatic document feeder (ADF) scanning. The documents may be for different purposes and he wants to save them into different files automatically after the scanning finishes. This way, it will greatly save the time.

So how can we achieve that? How to enable users to do that on your website or with your web application?

Read more

The difference between “Start with debugging” and “Start without debugging”

Today when I was browsing the MSDN VC++ forum, I saw a post asking the differences between “Start with debugging” and “Start without debugging”.

The original post is:

I’m having a problem with a network application I’m coding. I have this connection between a client and a server that only works when I start my application with “Start with debugging” and never with “Start without debugging”, both in Debug and Release configuration.

So my question is : what’s the differences with “Start with debugging” and “Start without debugging” that could possibly change the behaviour of a program? Because I don’t have a clue as of where to search for the problem… If it can help, my program is multi-threaded.

I also had the same question several years ago.

This issue is caused by the different variable initialization behavior of differnt run modes.

In the “Start with debugging” mode, the un-initialized variables are set to the default values. But in the “Start without debugging”, the variables are left random.

For example, you have:
int iHowMany;

In the “Start with debugging” mode, iHowMany is initialized to 0. But in the “Start without debugging” mode, the value of iHowMany is random.

It is easy to find all the un-initialized variables. The VC compiler generates a warning for using an un-initialized variable. Just go through the compiler warning list, find them and initialize them.