WPF Interview Questions and Answers

WPF stands for Windows Presentation Foundation. It's a re-invention of a UI for Desktop applications using WPF. Apart from dropping controls on "Windows Forms" just as developers have been doing for years, WPF provides an extra rapid boost to the application development including Rich User Interface, Animation and much more. In a nutshell the following things can be done using WPF: Draw normal controls and graphics. Can easily load/play audio and video files. Can provide smooth graphical effects such as drop shadows and color gradients. Can use shared styles which can be used across the same controls to provide the same theme, skin and design. Transforming objects including shapes, controls and video. Can create and animate 3D graphics. Can easily draw vector graphics that scale without jagged aliasing. Advantages Tight multimedia integration Resolution independence Hardware acceleration

XAML is a XML file which represents your WPF UI. The whole point of creating the UI representation in XML was write once and run it anywhere. So the same XAML UI can be rendered as windows application with WPF and the same UI can be displayed on the browser using WPF browser or Silverlight application.

An ICommand is a core component of MVVM. ICommand is frequently used in MVVM, it provides separation logic between a View and View Model (User Interface and Business Logic). XAML offers a way to bind your GUI event better by ICommand. ICommand requires the user to define two methods, bool CanExecute and void Execute. The CanExecute method really just says to the user, can I execute this Action? This is useful for controlling the context in which you can perform GUI actions. ICommand is very simple but it’s more interesting and complicated when you are using it in an application. ICommand integrates your User Interface to business logic or it’s making a direct communication between a View to a View Model. It also provides a mechanism for the view to update the model/view-model.

A StaticResource will be resolved and assigned to the property during the loading of the XAML which occurs before the application is actually run. It will only be assigned once and any changes to resource dictionary ignored. A DynamicResource assigns an Expression object to the property during loading but does not actually lookup the resource until runtime when the Expression object is asked for the value. This defers looking up the resource until it is needed at runtime. A good example would be a forward reference to a resource defined later on in the XAML. Another example is a resource that will not even exist until runtime. It will update the target if the source resource dictionary is changed.

Advantages of using WPF instead of Windows forms: XAML makes it easy to create and edit your GUI, and allows the work to be split between a designer (XAML) and a programmer (C#, VB.NET etc.). It allows you to make user interfaces for both Windows applications and web applications (Silverlight/XBAP). Databinding, which allows you to get a more clean separation of data and layout. Uses hardware acceleration for drawing the GUI, for better performance.

These two are totally different technologies. They do offer some interoperability layers to both directions, but other than that have nothing in common. Windows Forms is more or less a lightweight wrapper on top of Win32/MFC, which means its extensibility in .NET is not that good in all cases. WPF is a new UI framework implemented from scratch. WPF is also much more flexible when it comes to customizing the existing types. WPF is better for cross platform development and creating 'flashy' GUI's. However it requires a newer .net framework than WinForms and requires a dx9 compatible GPU or higher (which most people will have). WinForms is still a powerful technology which can often be developed at a faster pace than WPF however, in the end, both technologies can be used to achieve the same thing. WinForms is commonly used to develop business applications whereas WPF is often used to create more end-user based bits of software, apps etc.

Styles set properties on controls. ControlTemplate is a property shared by most controls that specify how they are rendered. To elaborate, you can use a style to group settings for a bunch of properties so you can re-use that to standardize your controls. Styles can be set explicitly on controls or applied too all of a certain type. Control Templates can be set by a style or set explicitly on a control to change the way it appears. All controls have default templates (and styles for that matter) that are embedded in the .net wpf assemblies.

Almost every WPF element has thread affinity. This means that access to such an element should be made only from the thread that created the element. In order to do so, every element that requires thread affinity is derived, eventually, from DispatcherObject class. This class provides a property named Dispatcher that returns the Dispatcher object associated with the WPF element. The Dispatcher class is used to perform work on his attached thread. It has a queue of work items and it is in charge of executing the work items on the dispatcher thread.

Pages are intended for use in Navigation applications (usually with Back and Forward buttons, e.g. Internet Explorer). Pages must be hosted in a NavigationWindow or a Frame.

Windows are just normal WPF application Windows, but can host Pages via a Frame container.

Use the Application.DispatcherUnhandledException Event. Be aware that there'll be still exceptions which preclude a successful resuming of your application, like after a stack overflow, exhausted memory, or lost network connectivity while you're trying to save to the database.

A ListView is a specialized ListBox (that is, it inherits from ListBox). It allows you to specify different views rather than a straight list. You can either roll your own view, or use GridView (think explorer-like "details view"). It's basically the multi-column listbox, the cousin of windows form's listview. If you don't need the additional capabilities of ListView, you can certainly use ListBox if you're simply showing a list of items (Even if the template is complex).

A StaticResource will be resolved and assigned to the property during the loading of the XAML which occurs before the application is actually run. It will only be assigned once and any changes to resource dictionary ignored. A DynamicResource assigns an Expression object to the property during loading but does not actually lookup the resource until runtime when the Expression object is asked for the value. This defers looking up the resource until it is needed at runtime. A good example would be a forward reference to a resource defined later on in the XAML. Another example is a resource that will not even exist until runtime. It will update the target if the source resource dictionary is changed.

They are not the same thing.

x:Name is a xaml concept, used mainly to reference elements. When you give an element the x:Name xaml attribute, "the specified x:Name becomes the name of a field that is created in the underlying code when xaml is processed, and that field holds a reference to the object." ([MSDN][1]) So, it's a designer-generated field, which has internal access by default. Name is the existing string property of a FrameworkElement , listed as any other wpf element property in the form of a xaml attribute. As a consequence, this also means x:Name can be used on a wider range of objects. This is a technique to enable anything in xaml to be referenced by a given name.

No, WPF does not replace DirectX. DirectX will still be still needed to make cutting edge games. The video performance of DirectX is still many times higher than WPF API. So when it comes to game development the preference will be always DirectX and not WPF. WPF is not an optimum solution to make games, oh yes you can make a TIC TAC TOE game but not high action animation. One point to remember WPF is a replacement for windows form and not DirectX.

Object: As WPF is created using .NET so the first class from which WPF UI classes inherits is the .NET object class. Dispatcher: This class ensures that all WPF UI objects can be accessed directly only by the thread who own him. Other threads who do not own him have to go via the dispatcher object.

**Dependency: ** WPF UI elements are represented by using XAML which is XML format. At any given

moment of time a WPF element is surrounded by other WPF elements and the surrounded elements can influence this element and this is possible because of this dependency class. For example if a textbox surrounded by a panel, its very much possible that the panel background color can be inherited by the textbox. Visual: This is the class which helps WPF UI to have their visual representation. UI Element: This class helps to implement features like events, input, layouting etc. Framework element: This class supports for templating , styles , binding , resources etc. And finally all WPF controls textbox , button , grids and whatever you can think about from the WPF tool box inherits from the framework element class.

The View is the client interface, input-output interface or the user interface. It collects all the user interface elements of the window, navigation page, user control, resource file, style and themes, custom tools and

controls. The view is unaware of the ViewModel and the Model, and vice versa the ViewModel and Model is unaware of the View and control is tightly decoupled. But the view model is aware of the needs of the view. They communicate by data binding and a dependency property or properties. ViewModel in MVVM ViewModel is a non-visual class. The MVVM Design Pattern does not derive from any WPF or Silverlight based class. The ViewModel is unaware of the view directly. Communication between the View and ViewModel is through some property and binding. Models are connected directly to the ViewModel and invoke a method by the model class, it knows what the model has, like properties, methods etcetera and also is aware of what the view needs. One View-Model can connect to multiple models, work like a one-to-many relationship and encapsulate business logic and data for the View. A ViewModel inherits some interface like INotifyPropertyChanged, icommand INotifyCollectionChanged etcetera.

User32: It decides which goes where on the screen. DirectX: As said previously WPF uses directX internally. DirectX talks with drivers and renders the content. Milcore: Mil stands for media integration library. This section is a unmanaged code because it acts like a bridge between WPF managed and DirectX / User32 unmanaged API. Presentation core : This is a low level API exposed by WPF providing features for 2D , 3D , geometry etc. Presentation framework: This section has high level features like application controls , layouts . Content etc which helps you to build up your application.

MVVM (Model View ViewModel) is a framework for making applications in WPF. MVVM is the same as the MVC framework. It is a 3-tier architecture plus one more layer. We can do loose coupling using MVVM. MVVM was introduced by John Gossman in 2005 specifically for use with WPF as a concrete application of Martin Fowler's broader Presentation Model pattern. The implementation of an application, based on the MVVM patterns, uses various platform capabilities that are available in some form for WPF, Silverlight Desktop/web, and on Windows. Many commercial applications, including Microsoft Expression products, were built following MVVM. Advantage of MVVM Modularity Test driven approach. Separation UI and Business layer as view and view model. Code sharing between pages and forms. Easy to Maintain. List of features of MVVM It separates the business and presentation layers, like MVP and MVC. Improve Structure/separation of concerns (View, ViewModel and Model). Enable a better Design/Developer Workflow. Enhance simplicity and testability. Enabled by the robust data binding capability of XAML.

No need to use a code behind file (minimalist code-behind file). Provides application development ability for multiple environments. Powerful Data Binding, command, validation and much more. The designer and developer can work together.

A Freezable is a special type of object that has two states: unfrozen and frozen. When unfrozen, a Freezable appears to behave like any other object. When frozen, a Freezable can no longer be modified. A Freezable provides a changed event to notify observers of any modifications to the object. Freezing a Freezable can improve its performance, because it no longer needs to spend resources on change notifications. A frozen Freezable can also be shared across threads, while an unfrozen Freezable cannot. Although the Freezable class has many applications, most Freezable objects in Windows Presentation Foundation (WPF) are related to the graphics sub-system.

Elements of a WPF user interface are hierarchically related. This relation is called the LogicalTree. The template of one element consists of multiple visual elements. This tree is called the VisualTree. The logical tree describes the relations between elements of the user interface. The logical tree is responsible for: Inherit DependencyProperty values Resolving DynamicResources references Looking up element names for bindings Forwaring RoutedEvents The visual tree contains all logical elements including all visual elements of the template of each element. The visual tree is responsible for: Rendering visual elements Propagate element opacity Propagate Layout- and RenderTransforms Propagate the IsEnabled property. Do Hit-Testing

RelativeSource (FindAncestor)

Top advantages of using Windows forms instead of WPF: WPF's in-box control suite is far more limited than that of WinForms. There's greater support in the 3rd-party control space for WinForms. (That's changing, but for now by advantage of time, WinForms has greater support in the community.) The major drawback of WPF is that Mono doesn't really support it for cross-platform (e.g., it doesn't work on Linux and Mac). Originally, Xamarian/Novella said they weren't going to implement it due to the complexity of implementation. I haven't seen anything to the contrary. Not saying it isn't, but their recommendation is to write model classes and then do a OS-specific front end. Even with WPF being open sourced, it may be built on something that isn't easily ported.

The SelectedItem property returns the entire object that your list is bound to. So say you've bound a list to a collection of Category objects (with each Category object having Name and ID properties). eg. ObservableCollection . The SelectedItem property will return you the currently selected Category object. For binding purposes however, this is not always what you want, as this only enables you to bind an entire Category object to the property that the list is bound to, not the value of a single property on that Category object (such as its ID property). Therefore we have the SelectedValuePath property and the SelectedValue property as an alternative means of binding (you use them in conjunction with one another). Let's say you have a Product object, that your view is bound to (with properties for things like ProductName, Weight, etc). Let's also say you have a CategoryID property on that Product object, and you want the user to be able to select a category for the product from a list of categories. You need the ID property of the Category object to be assigned to the CategoryID property on the Product object. This is where the SelectedValuePath and the SelectedValue properties come in. You specify that the ID property on the Category object should be assigned to the property on the Product object that the list is bound to using SelectedValuePath='ID' , and then bind the SelectedValue property to the property on the DataContext (ie. the Product). The example below demonstrates this. We have a ComboBox bound to a list of Categories (via ItemsSource). We're binding the CategoryID property on the Product as the selected value (using the SelectedValue property). We're relating this to the Category's ID property via the SelectedValuePath property. And we're saying only display the Name property in the ComboBox, with the DisplayMemberPath property).

<ComboBox ItemsSource="{Binding Categories}"
SelectedValue="{Binding CategoryID, Mode=TwoWay}"
SelectedValuePath="ID"
DisplayMemberPath="Name" />

WPF gives us a number of different mechanisms for handling events – they are bubbling, tunneling, and direct. These are all known as Routed events. Direct event - You are probably already used to the direct routed event. This is where the item itself handles the event that occurred. A good example would be handling he onClick-event of a mouse button in standard WinForms. This is where the event is raised in the GUI item and gets handled by said GUI element. Bubbling Event - Now we all like some bubbles in one form or another. Bubbling happens when the event is not handled by the element ( say a textbox) and the event "bubbles" its way up the UI containers which hold

it. For example, let's say you have a window that contains a panel and inside that panel you have a grid and inside the grid you have a textbox. If the event is not handled by the textbox, then it moves, is passed or "bubbles" up to the grid level (as the grid contains the textbox), if it is not handled at that level then the event bubbles further up the "tree" (known as a visual tree) to the panel where it may or may not be handled. This process continues until it is handled or the event "escapes" the top most element. Examples of a bubbling event would be something like a MouseButtonDown event. Or a Keydown event. Tunneling - Tunneling is the opposite of Bubbling. So instead of an event going "up" the visual tree, the event travels down the visual tree toward the element that is considered the source. The standard WPF naming definition of a tunneling event is that they all start with "preview" for example previewdownkey and previewmousebuttondown. You can catch them on their way to the "target" element and handle it. An example for this might be perhaps you have some controls inside a grid control and for some reason you have decided that no control within that grid will be allowed to have the letter "t" reach it.

The practical difference is that BindingList is for WinForms, and ObservableCollection is for WPF. From a WPF perspective, BindingList isn't properly supported, and you would never really use it in a WPF project unless you really had to.

ContentControl is a base class for controls that contain other elements and have a Content -property (for example, Button ). ContentPresenter is used inside control templates to display content. ContentControl , when used directly (it's supposed to be used as a base class), has a control template that uses ContentPresenter to display it's content. My rules of thumb (not applicable in every case, use your judgment):

1. Inside ControlTemplate use ContentPresenter
2. Outside of ControlTemplate (including DataTemplate and outside templates) try not to use any of them, if you need to, you must prefer ContentPresenter
3. Subclass ContentControl if you are creating a custom "lookless" control that host content and you can't get the same result by changing an existing control's template (that should be extremely rare).

Typically a control is rendered for its own sake, and doesn't reflect underlying data. For example, a Button wouldn't be bound to a business object - it's there purely so it can be clicked on. A ContentControl or ListBox , however, generally appear so that they can present data for the user. A DataTemplate , therefore, is used to provide visual structure for underlying data, while a ControlTemplate has nothing to do with underlying data and simply provides visual layout for the control itself. A ControlTemplate will generally only contain TemplateBinding expressions, binding back to the properties on the control itself, while a DataTemplate will contain standard Binding expressions, binding to the properties of its DataContext (the business/domain object or view model).

A WPF application has only one UI thread that handles all the UI interaction and user input. There is also a "hidden" thread responsible for rendering, but normally developers don't deal with it. Dispatcher / Thread relationship is one to one, i.e. one Dispatcher is always assoticated with one thread and can be used to dispatch execution to that thread. Dispatcher.CurrentDispatcher returns the dispatcher for the current thread, that is, when you call Dispatcher.CurrentDispatcher on a worker thread you get a dispatcher for that working thread. Dispatchers are created on demand, which means if you access Dispatcher.CurrentDispatcher and there is no dispatcher associated with the current thread, one will be created. That being said, the number of dispatchers in the application is always less or equal to the number of threads in the application.

The main difference is, that the value of a normal .NET property is read directly from a private member in your class, whereas the value of a DependencyProperty is resolved dynamically when calling the

GetValue()

method that is inherited from DependencyObject. When you set a value of a dependency property it is not stored in a field of your object, but in a dictionary of keys and values provided by the base class DependencyObject. The key of an entry is the name of the property and the value is the value you want to set. The advantages of dependency properties are as follows: Reduced memory footprint It's a huge dissipation to store a field for each property when you think that over 90% of the properties of a UI control typically stay at its initial values. Dependency properties solve these problems by only store modified properties in the instance. The default values are stored once within the dependency property. Value inheritance

When you access a dependency property the value is resolved by using a value resolution strategy. If no local value is set, the dependency property navigates up the logical tree until it finds a value. When you set the FontSize on the root element it applies to all textblocks below except you override the value. Change notification Dependency properties have a built-in change notification mechanism. By registering a callback in the property metadata you get notified, when the value of the property has been changed. This is also used by the databinding.

Clone actually copies the binding expressions. So if a property of the object is bound, it remains bound in the copy. CloneCurrentValues , on the other hand, only copies the current values, as the name implies. Bindings are not kept, so the values in the copy won't be updated if the source of the binding is modified.

I once wrote a PDF viewer using muPdf which renders bitmaps, that I render with WPF. What helps performance greatly is that I can render the page bitmaps on a background thread, freeze them, and then pass them to the UI thread. It is nice that WPF does not copy the image to freeze it, but the ability to do all this preparation on a background thread was the key benefit for me. From what I understand, all visuals need to be frozen so they can be safely rendered by the WPF render thread. If you render large unfrozen visuals, they will get cloned to frozen ones when WPF renders them. If you freeze your static bitmaps beforehand, WPF can just share the pointer with the render thread without cloning. Unfrozen objects may even get copied repeatedly if WPF is not aware wether the object is changed from the last time it was rendered. Frozen objects eliminate the need for all this copying.

A dependency property is used where:

1. You know the property is going to be the binding target i.e you are creating a user control/custom control and want property that should be binding driven.
2. You want automatic property change notifications (coerse and validation also).
3. We want value inheritance in styles,themes, parent or default value.
4. There is not need to create the properties on Model or ViewModel layer as dependency properties most of the time as that is not going to help much on memory saving front as most of the properties we define in model/VM will have values per instance as they will be constantly changing. Resolving Dependency property value is a burden in itself so making property dependency unnecessarily is not advisable.

Dependency properties and standard properties are quite different. The key features delivered by dependency properties are support for binding and animation. If you want to assign a value to a property using a Binding or template binding that property needs to be a dependency property. When animating a property the a dependency property can track both the current assigned value and the current animated value. One other advantage that is often overlooked is that storage is only needed for properties that have values assigned. A typical control can have a lot of properties but its rare code that assigns a new value to all the properties, in fact, most of the properties are left at their default value and only few are actually set. With

dependency properties the default values are stored as meta-data related to the property and do not require any memory allocated per control instance if the property remains unassigned. Dependency properties are not limited to controls (anything derived from DependencyObject can have then) however it is on controls or at least FrameworkElements where they are most useful.

I once wrote a PDF viewer using muPdf which renders bitmaps, that I render with WPF. What helps performance greatly is that I can render the page bitmaps on a background thread, freeze them, and then pass them to the UI thread. It is nice that WPF does not copy the image to freeze it, but the ability to do all this preparation on a background thread was the key benefit for me. From what I understand, all visuals need to be frozen so they can be safely rendered by the WPF render thread. If you render large unfrozen visuals, they will get cloned to frozen ones when WPF renders them. If you freeze your static bitmaps beforehand, WPF can just share the pointer with the render thread without cloning. Unfrozen objects may even get copied repeatedly if WPF is not aware wether the object is changed from the last time it was rendered. Frozen objects eliminate the need for all this copying.

Windows Presentation Foundation (WPF) resources provide a simple way to reuse commonly defined objects and values. Resources in WPF allow you to set the properties of multiple controls at a time. For example, you can set the background property on several elements in a WPF application using a single resource. The best way of defining the resources is on a Window or Page element level. Any resource that you define for an element also applies to their child elements of that element.

Following are the differences between XML and XAML:

1. All XAML docs are also authentic XML documents. However, the reverse cannot be true.
2. XAML is a declarative application language while XML is a markup language.
3. XML is primarily used in web applications. In contrast, the XAML is used to design controls of Windows and other web applications.
4. XAML focuses on object properties, definition and the relationship among them.
5. XML is a markup language produced by W3C and is used to describe other markup languages.

WPF styles work just like CSS style, In the CSS we define styles for a control and we reuse the same where ever we need in the application, same way the styles in WPF allows to define the properties and can be reused in the application.

Visibility.Hidden hides the control, but reserves the space it occupies in the layout. So it renders whitespace instead of the control. Visibilty.Collapsed does not render the control and does not reserve the whitespace. The space the control would take is 'collapsed', hence the name.

No, XAML is not meant only for WPF. XAML is a XML-based language and it had various variants. WPF XAML is used to describe WPF content, such as WPF objects, controls and documents. In WPF XAML we also have XPS XAML which defines an XML representation of electronic documents. Silverlight XAML is a subset of WPF XAML meant for Silverlight applications. Silverlight is a cross-platform browser plug-in which helps us to create rich web content with 2-dimensional graphics, animation, and audio and video. WWF XAML helps us to describe Windows Workflow Foundation content. WWF engine then uses this XAML and invokes workflow accordingly.

WPF controls can be categorized into four categories: Control: - This is the basic control with which you will work most of time. For example textbox, buttons etc. Now controls which are standalone control like a button , text box , labels etc are termed as content control. Now there are other controls which can hold other controls, for instance itemscontrols. Itemscontrol can have multiple textbox controls, label controls etc. Shape: - These controls help us to create simple graphic controls like Ellipse, line, rectangle etc. Panel: - These controls help to align and position the controls. For instance, grid helps us to align in a table manner, stack panel helps for horizontal and vertical alignment. Content presenter: - This control helps to place any XAML content inside it. Used when we want to add dynamic controls on a WPF screen.

There is no difference between “x:name” and “name” , “name” is short hand of “x:name”. But in classes where you do not find “name” property (this is a rare situations) we need to use “x:name” property.

Both the namespaces helps to define/resolved XAML UI elements. The first namespace is the default namespace and helps to resolve overall WPF elements. The second namespace is prefixed by “x:” and helps to resolve XAML language definition. For instance for the below XAML snippet , we have two things one is the “StackPanel” and the other is “x:name”. “StackPanel” is resolved by the default namespace and the “x:name” is resolved by using “xmlns:x” namespace.

<StackPanel x:Name="myStack" />

“xmlns” stands for XML namespaces. It helps us to avoid name conflicts and confusion in XML documents.

Remember: - ABCDEFG A - Anywhere execution ( Windows or Web)

B - Bindings ( less coding)
C - Common look and feel ( resource and styles)
D - Declarative programming (XAML)
E - Expression blend animation ( Animation ease)
F - Fast execution ( Hardware acceleration)
G - Graphic hardware independent ( resolution independent)

Command Design Pattern is one of the most powerful design patterns in object oriented design patterns. This pattern allows you to decouple the request of an action from the object that actually performs an action, in other words a command pattern represents an action as an object. A Command object does not contain the functionality that is to be executed. This removes the direct link between the command definitions and the functionality and it’s promoting a loose coupling. When you want to implement operations based on the user request then the command pattern is the best pattern to handle your object. The following are the members of the Command Design Pattern: Client Invoker Command Concrete Command Receiver

A Value Converter functions as a bridge between a target and a source and it is necessary when a target is bound with one source, for instance you have a text box and a button control. You want to enable or disable the button control when the text of the text box is filled or null. In this case you need to convert the string data to Boolean. This is possible using a Value Converter. To implement Value Converters, there is the requirement to inherit from I Value Converter in the System.Windows.Data namespace and implement the two methods Convert and Convert Back.

There are two types of resource, namely, Static Resource - The value of StaticResource is determined at the time of loading. Dynamic Resource - Dynamic Resource we use in a situation where we want to change the value of property at run time.