C# 4 All

Today we are going to be taking a look at how to build a single instance application in WPF. Not a single instance in this sense, but in the sense that you can only run one instance of the application at a time. Generally, you can run as many instances of an app at once (at least until you run out of resources). For instance, Notepad. You can run Notepad a dozen times, and you will get a dozen separate Notepad windows, and a dozen separate lines in "Task Manager" that read "notepad.exe". Killing one of those lines just kills one of those Notepad windows, and the rest live on happily. On the other hand, you have an application like Firefox. At any given time, there should only be one line in Task Manager that reads "firefox.exe". This is because every time you hit the Firefox shortcut, or double click the executable, instead of running a new instance of the app, the running instance gets a message (which is how Firefox knows to open a new browser ...

So in the world of Windows, there is this horribly awful and horribly useful thing called a metafile (sometimes called WMF, sometimes EMF). In general terms, it is essentially a transportable list of GDI commands for drawing an image or set of images. Applications like Microsoft Word use it for transferring collections of graphical objects to other applications through the clipboard or drag & drop. It has been around for quite a while, and so is supported as a standard clipboard/drag&drop format by many applications. However, as soon as we enter the WPF world, we have a problem. WPF knows nothing about GDI - you can't convert from a WPF Visual into a list of GDI commands. So the very basic infrastructure of a metafile no longer meshes with the way WPF works. But don't give up yet! While it isn't possible to go from a WPF visual to GDI commands, it is possible to go from a visual to a bitmap. And, thankfully, a bitmap can be placed inside of a metafile....

If you've worked for a while in WPF doing any kind of complicated user interface, you may have noticed that while WPF has some great methods for getting the mouse position relative to an element, there is one serious problem - the returned position is sometimes wrong . Yeah, I know it is hard to believe, but it is true. When I first ran across the problem, I tore out my hair for the better part of a day trying to find what was wrong with my code - only to eventually figure out that this is a known issue with WPF. This problem is actually even documented on the MSDN page about the standard WPF function to get mouse position. The following quote is taken verbatim from the MSDN page on Mouse.GetPosition : During drag-and-drop operations, the position of the mouse cannot be reliably  determined through GetPosition. This is because control of the mouse (possibly  including capture) is held by the originating element of the drag until the drop  is completed, with ...

About two weeks ago, we had a tutorial here at SOTC on the basics of printing in WPF . It covered the standard stuff, like popping the print dialog, and what you needed to do to print visuals (both created in XAML and on the fly). But really, that's barely scratching the surface - any decent printing system in pretty much any application needs to be able to do a lot more than that. So today, we are going to take one more baby step forward into the world of printing - we are going to take a look at pagination. The main class that we will need to do pagination is the DocumentPaginator . I mentioned this class very briefly in the previous tutorial, but only in the context of the printing methods on PrintDialog , PrintVisual (which we focused on last time) and PrintDocument (which we will be focusing on today). This PrintDocument function takes a DocumentPaginator to print - and this is why we need to create one. Unfortunately, making a DocumentPaginator is not as easy as...

And here we are, back with another installment of our ongoing series of ListView tutorials. And hey, I think that I got this one out in a reasonable amount of time - it has only been a month since Part2 was published (as opposed to the 8 months between Part 2 and Part1 ). Today we are going to take a look at how to do in-place editing using a ListView, which, because the ListView is not a full blown datagrid, takes a fair amount of work. Now, I do realize that there is an actual WPF DataGrid control in the works (and in fact, they just released v1 about a month ago). The plan is that it will be integrated into the next release of the .NET framework, but for now you can always grab the source here if you want to play around with it. I've poked at it a little bit, and you never know, maybe I'll write up a tutorial on it at some point. But for now, we are focusing on the ListView, which is still a very useful control all on its own. Of course, we need to start off w...

While WPF and XAML make the common 90% of UI programming quite easy, sometimes it gets a little odd in those other 10%. For instance - the visual tree. Most of the time it works great, and you never need to do anything special with it. But what about when you specifically want to give a user control children? Or maybe you want to give an adorner an actual visual child, instead of using OnRender? It isn't really obvious right away how to go about doing that. But while it is not obvious, it is possible - and so today we are going to take a look at using VisualCollection to do those things. Specifically, we are going to create an Adorner to be used in an AdornerLayer that accepts a Visual as content. This is not possible right out of the gate, because Adorners don't have any built in way to have Visual children, and we can't use any of the normal controls that do ( Panel , ContentPresenter , etc...), because only Adorners can be placed on an AdornerLayer. Now,...

So I just noticed that we have never talked about the clipboard before - and for such a common (and annoying) part of software, that is just horribly lax on our part. So here I am to rectify the situation - we will be taking a look today at how to use the clipboard in WPF. Working with the clipboard can be quite painful sometimes in .NET applications, since all we get is is a very thin wrapper around the OLE clipboard calls (and so if anything goes wrong, nasty COM exceptions get thrown). It also doesn't help that since the clipboard is a shared resource among all applications on a computer, your application is not guaranteed to be able to use it at any given point in time. So today we are going to take a look at how to deal with those situations while adding data to and getting data from the clipboard. And don't worry, we will look at using our own custom formats for that data as well. So first off, how do you get to the clipboard at all? Well, you use the Clipboard...