Consider the following piece of XAML (part of an Image Viewer application), that wants to set the Window title (in WPF) based on the currently loaded image file:

This assumes that a DataContext exists, and exposes a property named ImagePath. This works well if such an object actually exists. But what happens when the application starts up and there is no image loaded yet, meaning the DataContext remains null? The Title would show nothing, because the binding fails. How can we fix that?
One way would be to create a dummy DataContext with the ImagePath property set to some value we want. But that’s cumbersome and limiting. What if we wanted a completely different title when there is no image?

Fortunately, there is a way. The FallbackValue property of the Binding object (actually BindingBase) allows setting a value if the binding can’t complete. Here’s a way to get something with a null DataContext:

This shows the fallback value when the binding is unable to provide a value.

• Read more
• No comments

In his post about running a process as a standard user from an elevated process, Aaron Margosis uses a technique that gets the access token of the shell process (typically explorer.exe) and uses that token to launch the new process (Sasha Goldshtein also blogged about that).

The first thing his code does is try to locate the shell process id. One way is to look for “explorer.exe” in the list of processes, but that’s a bit limiting, as there may be a different shell, or it may have been renamed for whatever reason. His code calls GetShellWindow to get the shell window handle, followed by GetWindowThreadProcessId that returns the window’s creator thread (and optionally its parent process). A similar looking function is GetDesktopWindow, which seems at first glance as a better candidate, or at least an equivalent. Let’s test that:

GetImageFileName is a simple helper for getting the process image name:

This is the result of running this code:

The difference is evident: GetShellWindow returns the “program manager” window created by explorer.exe, while GetDesktopWindow returns the window created by the Windows subsystem process (csrss.exe). This code requires running elevated, so that opening a handle to csrss.exe succeeds, as it runs (naturally) under the all powerful system account.

What’s the relation between these two Windows? We can find out using the Spy++ utility (spyxx.exe from the Visual Studio tools). Run Spy++ (by default elevated). You should see something like this:

If the Windows window is not shown, select Spy->Windows from the menu. Note that the root window handle is the same as the desktop window handle reported by our simple application. This window is owned by csrss.exe. That means it exists whether a shell process exists or not.

Now let’s find the shell window. Select Search->Find Window from the menu and type the handle reported by the application (1013A in this case) (hex is ok).

Click OK. The selected window is now this one:

This is the “Program Manager” of explorer.exe. How can we verify that? Right click the window and select Properties:

Click the Process tab:

Now click the shown process id:

This is indeed explorer.exe.

If we go back and look at the shell window again, and go up in the tree to its parent, we would find it to be the desktop window itself!

• Read more
• No comments

The WeakReference class that exists since .NET 1.0 can be used to wrap an object while not being the one keeping it alive. This may be useful in an “Observer” pattern scenario, where a client registers for some notification, but “forgets” to unregister. That means that with a normal reference, even if the client is no longer needed, it keeps getting notifications because the server object keeps a strong reference to the client.

Here’s a simple example:

A simple client (observer) may be implemented like so:

Now, we can test:

How many times would the observer be notified? Three times. The call in line (12) to GC.Collect is not enough, because the client is not garbage – the subject holds a strong reference to the client.

The solution is obvious – just call Detach on the subject and you’re good. The problem is that sometimes clients forget to detach, and sometimes it’s difficult to call it in the right moment – if the client is used from different threads, for instance, Detach needs to be called at the right time, i.e. not too soon.

The subject can be more defensive – not hold on to the observer too tightly using the WeakReference class. Here’s a revised subject:

Every observer is wrapped in a WeakReference. The Target property points to the real object, or null, if it has since been garbage collected. Let’s test it:

Now we only get two notifications! That’s because the subject is holding a weak reference to the observer, so cannot be the one keeping it alive if no other string references exist.

The WeakReference class has two “issues”:

1. It does not implement IDisposable, so the underlying GCHandle is freed only when it is garbage collected.

2. It’s not generic (somewhat understandable, as it exists since .NET 1.0)

We can fix both these issues by either deriving from WeakReference (it’s prepared for that, most of its members are virtual), or create our own implementation.

I decided to go for the latter, as the WeakReference is not immutable (it’s target can be replaced) and I like immutability these days. We can also simplify it a bit. Here one way to go about it:

Now its usage is a bit more intuitive:

My WeakReference<T> is not serializable (the original WeakReference is), but that’s not  too difficult to add.

• Read more
• 1 comment(s)