Upcoming WPF Presentations

I just returned from a wonderful week of vacation in Paris. The architecture, cuisine, wines/cognacs/armangacs/calvados, art, music, and beautiful women recharged my batteries and inspired me. Now that I’m back in the swing of things here in New York City, it’s time to make a few announcements regarding my WPF-entrenched alter ego.

I will be giving a WPF presentation on October 20^th, 2007 at the Charlotte Developers GUILD Code Camp, in North Carolina. It should be a lot of fun, so if you’re in the area you might want to stop by. My buddy Karl Shifflet announced the fact that I’ll be speaking there with great enthusiasm, so hopefully I will live up to his expectations! 🙂

On Tuesday, December 11^th I will be giving my WPF presentation at the Northern New Jersey .NET User Group.

Also, my WPF presentation at the Boston .NET User Group has been moved from November 1^st to Thursday December 6^th.

Advertisement

VSLive was great

I gave my WPF presentation at VSLive! NYC today.  It went quite well, and the audience became more and more engaged as the presentation progressed.  As promised, I’ve made my presentation application source code available.  Feel free to download it from this page: https://joshsmithonwpf.wordpress.com/presentation-app/

I’m looking forward to attending the other presentations over the next couple of days!

Modifying the auto tooltip of a Slider

This blog post answers a question on the WPF Forum which asks how to programmatically affect the text in a Slider’s auto tooltip.

Slider has a nice feature where it displays an “auto tooltip” as the user slides the thumb.  The tooltip displays the current value of the Slider, and it follows the thumb as the user slides it back and forth.  Slider exposes two properties that allow you to affect the auto tooltip, AutoToolTipPlacement and AutoToolTipPrecision.  The latter allows you to affect how accurate the tooltip’s text is, relative to the Slider’s value.  What is not possible, however, is to modify the text in the auto tooltip.  This blog post shows one workaround for that problem.

I tried to gain access to the auto tooltip in many ways, but none succeeded. As a last resort, I decided to use a little reflection to gain access to the _autoToolTip field in Slider.  After poking around in Reflector I realized that the auto tooltip’s content is only updated in two virtual methods: OnThumbDragStarted and OnThumbDragDelta.  Armed with that information it was trivial to create a Slider subclass which makes it possible to format the auto tooltip’s display text.

Using the FormattedSlider is simply a matter of setting its AutoToolTipFormat property to a format string, as seen below:

The demo application looks like this when you run it:

Using a format string to modify the tooltip text is just one option.  If you have more involved needs than just wrapping the Slider’s value in some text, you might want to change the AutoToolTipFormat property to a dependency property named something like AutoToolTipContent, which could then be set via triggers.

Download the demo project here: FormattedSlider (demo project)  Be sure to change the extension from .DOC to .ZIP and then decompress it.

Annotating Images

I just published a new article on CodeProject.  This one is a continuation of my earlier work on annotating images.  A more fully featured and thoroughly tested solution is described in the article.  If you are interested in checking it out, here is the link: http://www.codeproject.com/WPF/AnnotatingAnImageInWPF.asp

WPF vs. Windows Forms

During my WPF presentation at the NYC .NET Developer Group, someone asked me a simple yet difficult question.  Allow me to paraphrase: “I work for a bank’s IT department.  We build Windows Forms applications which basically just show large tables of numbers, allow the user to sort them, edit them, etc.  There is some simple business validation in place, and a few other standard LOB-application things you’d expect.  We have no need for UI candy, animations, 3D, etc.  Why should we use WPF and what can I say to management to convince them that we should use WPF in upcoming projects?”

When he asked that question, I did not have an answer for him.  Ever since that night I have been thinking about it, and even had the chance to discuss it with Tim Sneath; who had some excellent perspectives on the question.  Here is my much delayed answer for the fellow who asked that question.  Please note that the answer I’m about to give does not necessarily reflect Tim Sneath’s opinion of this topic, nor am I claiming that he supports the view I’m about to express.

WPF is not intended to replace Windows Forms.  I used to think it was intended to be a replacement for WinForms, but it is not.  WinForms is still alive and well, and will continue to be enhanced and supported by Microsoft for years to come.  WPF is simply another tool for Windows desktop application developers to use, when appropriate.  If the type of applications you develop would not benefit from the features found in the WPF platform, then perhaps WPF is not the correct platform for you to use. 

So when should one use WPF instead of WinForms, and vice versa? 

First off, WPF is not just for applications which simply require “eye candy.”  That is the most common and frustrating misperception about WPF which I’ve encountered.  Sure, WPF has a lot of support for flashy visuals and animations.  But that’s not all it’s good for.  If you’ve worked with WPF for any substantial period of time you are probably well aware of this fact, so I won’t keep harping on the issue.

WPF is an especially great platform to use if your applications involve various media types.  For example, if you need to incorporate video, or documents, or 3D content, or animated transitions between a sequence of images, or a combination of any of the above.  WPF is also great if you need to create a skinned user interface, or if you need to bind to XML data, or dynamically load portions of a user interface from a Web service, or want to create a desktop application with a Web-like navigation style.

Another great reason to use WPF is if you have a team of developers who are bored with WinForms and are itching to get into something new and cool.  Of course this is not as powerful and compelling a reason from a business perspective, but nothing promotes employee retention better than keeping the employees interested in their jobs.

WinForms definitely still has a role to play, despite the fact that WPF has hit the scene.  If you are building applications with no need for the extensive modern functionality in WPF, then there is no compelling reason to leave behind a time-tested developer-approved platform.  WinForms certainly has more 3rd party controls available, online resources, developer communities, etc. than WPF currently does.  It’s much easier to find WinForms developers than WPF developers.  Also, WinForms currently has a much better design-time experience in Visual Studio than WPF.  That fact alone is a very compelling reason to stick with WinForms for a while.

Lastly, don’t forget that it is possible to use WPF controls in a WinForms app, and WinForms controls in a WPF app.  If you have a substantial investment in a WinForms code-base, but want to use some aspect(s) of WPF, you can leverage the interop support to make that possible.  Just be sure to read up on the limitations involved with WinForms-WPF interop before getting too far down that path.