Yesterday I passed the exam MCTS Windows Applications Development with Microsoft .NET Framework 4 which completes my seventh MCTS – although the first in Windows client development.
I did an MCTS exam a while ago, and I was a bit shocked how easy it was – I “overprepared” myself.. I thought that you can pass this one with a deep understanding of the .NET Framework and a little WPF knowledge – but this way, you’d need to use your common sense.
There were some questions on WPF and Windows Forms integration, but you could figure them out with a little thinking. Also there were some on UI aligning, UAC, ClickOnce abd parallelism. The questions were that MCTS type, so they focused on how to do something instead of why, but that was expected.
My next goal is the .NET 4 Windows MCPD exam – which is filled with cool architectural decisions, as I looked briefly on the skills measured section.
May include but is not limited to: enabling data binding and animation, property metadata, property change callbacks
WPF adds a new concept to the classic .NET property world, namely dependency properties. They introduce some nice new features such as property value inheritance and change notification. You can imagine that most of the WPF properties are dependency properties.
Like almost anything else, dependency properties are coming in multiple variations. The first is a “simple” dependency property, and the second is an attached dependency property. More info about the latter is in the end of this post.
What do we need to define a classic dependency property (that is not an attached one)? Three things:
- defining the property
- registering it
- wrapping it within a normal .NET property
Well, that doesn’t sound like a big issue, so let’s define one!
First we need to define the property – in the class we’ll use it in. To do so, we need to add a static field of type DependencyProperty (this field might be shared with other elements, so it’s a good point to define it as static). Also, you need to define the field with the readonly keyword, so it can only be set in a static constructor. The whole code might look as follows: Read More…
Dragging and dropping pieces of information is fun. Sometimes I do it too – maybe once a week, maybe twice. The point is that you can do it in WPF, and as the title says: within and across applications.
Let’s see a fairly basic example: drag something and drop it to another control. First we need to handle the MouseDown event on the source control (you must hold down the mouse, move it to another place, and release it there). We need a method there:
private void source_MouseDown(….)
Label lab = (Label) sender;
DragDrop.DoDragDrop(lab, lab.Content, DragDropEffects.Copy);
Then you need to handle the target’s drop event, like this:
private void target_Drop(object sender, DragEventArgs e)
((Label)sender).Content = e.Data.GetData(DataFormats.Text);
These code samples were from the book Pro WPF 4 in C# 2010.
Of course you could improve this drag and drop experience to check whether or not data is present before “dropping” it on the target. There’s an event just for that, and it’s called DragEnter. A perfect candidate to check things like the format and the availability of the data to be dropped.
If you’d like to drag and drop across applications, then I have a nice link for you. It’s a little code written by Scott Garland who seemed to be a little upset when he tried to do the thing. Anyway, don’t give up the hope – you need a class implementing ISerializable or IDataObject to begin with, and the rest will be simple…
May include but is not limited to: animation, data binding, dependency properties
Since .NET 3.5, we get a nice and neat class, PresentationTraceSources to debug some kinds of WPF-specific things, like animation, data binding and dependency properties. To make it work, first you’ll need to set a reference to the CLR namespace System.Diagnostics in your XAML code. This is how could it be done:
<Window xmlns:diag=”clr-namespace:System.Diagnostics;assembly=WindowBase” />
Then with the new XML schema prefix diag, you can use PresentationTraceSources to emit error information. You should use the attached property TraceLevel, which is an enumeration, with the following members:
- None: no additional information will be emitted.
- Low: traces some additional information.
- Medium: traces a medium amount of additional information.
- High: traces all additional information.
All hail MSDN, the best resource available. I liked the explanation very much, and copied it here, so you’ll all know that TraceLevel.Medium produces medium amount of additional information. What a shame that we won’t know what counts to be additional, and what is just basic info.
Anyway, the attached property can be set on the following classes: BindingBase and its derivatives, BindingExpressionBase and the derived types, Object- and XmlDataProvider. Oh, and an example on how to use this property:
<Binding Path=”myProperty” diag:PresentationTraceSources.TraceLevel=”Low” />
May include but is not limited to: configuring and integrating UAC by using ClickOnce deployments; setting appropriate security permissions to deploy the application
I have read some very controversial information about UAC and ClickOnce and WPF, so I decided to get onto the bottom of things.
By default, a WPF application needs Full Trust permission, because it needs to call unmanaged code to build its window. However, Full Trust is the devil itself (and is obviously a mock in the philosophy of least principle) so you should configure your applications to have the relevant rights.
This can be done in the Project Properties menu’s Security tab. There you can edit ClickOnce security settings. You can even set the application to run in Partial Trust (which will be the level your users will use it). Even better, you can set Visual Studio to debug in Partial Trust mode – a very nice thing, because you’ll surely see what your end users will. You can set the Local Intranet and the Internet zones’ security settings. You can even define a custom one, where you can edit the resulting XML file by hand. For some strange purposes, the ClickOnce deployment model doesn’t allow demanding administrative rights (at least you cannot specify the requestedExecution level element’s level attribute to requireAdministrator or highestAvaliable). I think this makes sense, because the whole point of ClickOnce development is to get an application up and running with a couple of mouse clicks.
As for configuring UAC with ClickOnce I didn’t find any useful information. In fact MSDN and the rest only told me that it’s against the nature of ClickOnce to have UAC support. If you need some, then you will need to write a shell application which requests for a UAC prompt, and call your ClickOnce setup from there. A stinking but working solution.
May include but is not limited to: accessing the Visualizer, drilling down the visual tree; viewing and changing properties
All editions of Visual Studio 2010 (with the exception of Visual Web Developer 2010) come with a cool little feature called the WPF Visualizer. This tool lets you search and drill down the visual tree produced by WPF.
The only thing isn’t very straightforward with this tool is how to access it. You can reach it from a couple of locations (the Watch, the Autos or the Locals window) or just by setting a breakpoint. To get the tool, you need to click on the little magnifier icon which appears when you browse WPF elements. Then you get a nice window, with a treeview on the left and a grid on the right. I think you’ll be able to handle the stuff. You can even search for properties/elements, and filter properties shown in the grid, too.
I don’t think there’s pretty much else to say on the topic – practice make perfect!
May include but is not limited to: configuring the installation of a WinForms, WPF, or XBAP application; choosing appropriate settings to manage upgrades
Excuse me for putting this one first, but I needed something from another topic to dig into, because I got overwhelmed by data binding. So ClickOnce!
As you may know, ClickOnce is a deployment and distribution technology. Most of its functionality lives in dfsvc.exe. You can publish your application directly from Visual Studio with it, and can be very happy with the results, because if you’d set up the deployment appropriately, you’ll get automatic update checking and other cool features.
On the other hand, ClickOnce is very limited. You won’t be able to get inside to the setup menu, nor to tell the engine where you’d like to install your application. But as its name suggests, you can deploy an app by just a couple of clicks (yes, even by one click).
OK let’s get started. There are several places you can install your applications with ClickOnce. You can use a disk path, a UNC share, an FTP server or a web site. All of them have their pros and contras, and I think you’ll be able to figure them out yourself. After specifying this, you will be asked how the users will install your application. You can specify a web site for that (although you’ll need IE or Firefox with a little plugin to install directly from the browser). You can specify a UNC path, or tell the engine that you’d like to install from a CD/DVD. If you specify CD/DVD, then you’ll be asked whether or not you’d like to let your application check for updates, and if yes, where to do that. Read More…
May include but is not limited to: implementing INotifyPropertyChanged, using INotifyCollectionChanged(ObservableCollection)
We’ve discussed that WPF has some nice data-binding support which lets us implement two-way bindings. But it won’t work from itself, especially not for you domain classes. If you’d like to receive change notification support, then you need an interface what will do just that for you. It’s called INotifyPropertyChanged, and exposes one event, with the following signature:
public event PropertyChangedEventHandler PropertyChanged;
It’s up to you to fire this event whenever one of your properties changes. A decent example: Read More…
May include but is not limited to: binding options, static and dynamic resources, element bindings, setting the correct binding mode and update mode, binding to nullable values
I think one of the biggest points in WPF is data binding. It’s incredibly easy to bind a form or a list to an object or to a collection of objects. You just set the container’s DataContext property to your custom object, set up the XAML markup and you have bound your data.
But the Binding class has so many properties you can set that it’s easy to get lost. I’ll show you some properties used in basic data binding scenarios:
- Mode: the binding mode to use. It has five potential values, which are:
- TwoWay: updates the target property or the property whenever either of them changed.
- OneWay: update the target property whenever the source property changed.
- OneTime: updates the target property only at startup, or when you change the underlying DataContext.
- OneWayToSource: updates the source property whenever the target property changed.
- Default: delegates the task to handle binding changes to the target properties target. User-editable properties usually have two-way bindings, others usually have one-way bindings. But exceptions occur.
- Path: the path of the property to bind to, such as TextBox.Text.
- StringFormat: when the target property is a string, you can set its format. It is like a Converter, but on a much more basic level.
- TargetNullValue: if you bind to a nullable value which happens to be null, you can specify another value to bind to. If you’d like to show a static text, like “Value is null”, you need to wrap it between parentheses.
- UpdateSourceTrigger: it defines the time to bind. The default value is LostFocus, which means that the property gets bound when the focus is lost (you navigate further). Other possible values are explicit (binding only occurs when you call it from code) or PropertyChanged, which updates the binding in the moment of a property change.
So that’s all you need to know about the Binding class for now. It’s worth knowing that you can bind elements together. It hasn’t got much sense, but for example, you can bind together a TextBox and a Slider. Then if you move the slider, your textbox will be updated – or if you type in text, the slider will jump to that position (of course if you set up the binding this way).
May include but is not limited to: implementing custom value converters, implementing multivalue converters
Once I wrote a WPF blog management tool, and as all of us know, blog posts tend to have tags. These tags can tremendously facilitate navigation by letting you find related contents in a matter of seconds. But how would you work with them from a management point of view.
I bound my form to a Post object, which had a collection of TagPost objects (IEnumerable<TagPost>) a TagPost is just a switchtable between Posts and Tags with a unique ID. I decided to visualize tags as a comma-delimited list, like this:
WPF, 70-511, Exam
But I had a collection of TagPost, which didn’t look like this. How could I do this without messing my data binding code (which happened to be one statement)? The answer was using value converters.
A value converter is a class that implements the IValueConverter interface. It has two methods returning Object, Convert and ConvertBack, which take the following parameters (both of them): Read More…