C# 4 All

We have taken a look at printing in WPF twice before here at SOTC - first with a simple tutorial on just getting somethingprinted , and then a more complex one on pagination . Today we are not going to focus much on the printing side of things, but more on the printer side. For example, how do you get a list of the printers available on the system? Or their capabilities? If you need the answers to those questions, then this is the tutorial for you. Today, we will be creating a little sample application that finds all the printers on your system (both local and network printers) and lists them out. When you pick a particular printer, you will get a list of the supported page sizes for that printer. Once you pick a page size, you can then print a test page to the chosen printer at the chosen page size (and you can even pick landscape or portrait). Oh, and did I mention that we never have to show the standard print dialog for any of this? Ok, to start off we first have

One WPF control that we haven't taken a look at here is the TreeView . Well, no more! Today we are going to rectify that, as we build an application that not only uses the TreeView , but also dynamically loads data into it on demand. We are going to cover a couple other new topics as well, including HierarchicalDataTemplates and CompositeCollections . So what are we building? A pretty simple app that pulls the tree hierarchy of categories and images from GamingTextures and displays it in a TreeView . Gaming Textures has a couple of calls that we can make to get lists of base categories and then the children for each category - so we will be making a web request on demand to get the children for a category, parsing the resulting JSON into C# objects, and then adding those items to the tree view. For example, we start out with the list of base categories: When an item is expanded, we send off a request for the children: And once we have the children, we

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 much of th

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