Rick Strahl's Weblog  

Wind, waves, code and everything in between...
.NET • C# • Markdown • WPF • All Things Web
Contact   •   Articles   •   Products   •   Support   •   Advertise
Sponsored by:
Markdown Monster - The Markdown Editor for Windows

WPF Experiments: Changing a Live Writer Plug-in to use WPF


:P
On this page:

Ok so I had a little free time on my hands this weekend and was looking for a simple something to use WPF on. A few weeks back I'd been playing with an Justin Brown's Amazon book plug in for Live Writer, which is part of the Windows Live Writer Plugins on CodePlex. Back when I first looked at his plug-in which is great, I added a few small enhancements like configuration of the Amazon Service and Associate ID and a few minor changes in the way the pop up window and resulting HTML formatting worked.

The original version looks something like this:

It works but it's pretty basic and not real easy to tell much about the book information. So, why not experiment with creating a simple WPF form and create a richer display for the list, which should be easy. I don't know about easy, but what I ended up with is this:

Definitely a much more visual and more informative view of the data.

But I'd rather not admit how much time it actually took to build this simple freaking dialog <s>. Well, maybe I will...

There are a few other operational issues that stuck out at me with this 'new and improved' form.

First note that this form runs in combination with Live Writer, which is a Windows Forms application. In theory this shouldn't work - WPF forms can't easily co-exist with Windows Forms applications, although you can host WPF content using a special Windows Forms control that can be embedded into existing forms.

So why does this work here? It works merely because the form above is a dialog and sitting in a fixed message loop that apparently works properly with WPF and Windows Forms not stepping on each other. So this is really a specialty case and not adequate for common operation. Bummer - it would be nice to add some WPF functioality selectively to existing applications where needed. In order to do this requires a little work as you have to add the WPF page and referenced assemblies manually.

It works, but keep in mind that this requires .NET 3.0 installed to run and is a special case scenario that I kind of stumbled upon by accident.

So, yes it works, but there are a few other issues here that I thought I would point out. First off loading that WPF form is slow, slow, slow. It takes somewhere between 10 - 15 seconds to load that form. The WinForm pops up instantly. This is somewhat understandable I suppose given that the WPF services need to startup in the process. But if you thought WinForms take a long time to load just wait 'til you run a WPF form <s>.

Another minor issue/nit is that the actual display of the WPF form. Notice that on my system I run with ClearType off because it gives me a headache (and I'm not kidding - it hurts my eyes). So when you look at the text in Windows Writer, and compare with the text of the WPF form you can really see the difference in clarity. The WPF form ALWAYS uses anti-aliasing regardless of what the system settings are and you can see some font rendering issues especially in the bold text in the list, but even the plain text looks crappy. Experimenting with Fonts makes some difference but not much. Frankly the way the text looks is less than stellar using standard Tahoma. FWIW, turning on ClearType makes no difference on this crappy font rendering.

Not trivial

As I've mentioned on previous occasions i've been spending quite a bit of time reading and experimenting with rudimentarty concepts of WPF over the last 2 months or so, but I've really not spent any time building anything useful beyond drawing a few circles with funky fills <s> - not quite but it's not too far off the mark. WPF is a big topic and getting a handle on the object model and how the containership and eventing works is quite a head trip. To be fair I think it's is honestly quite well thought out and makes sense, but it's just not the kind of thing that (I at least) can absorb in one setting. I've been reading through several books several times now and I think I'm slowly getting the concepts into my skull. I think it's fair to say that WPF is exremely powerful in what it provides but getting started with it is anything but uhm powerful.

The biggest problem is that currently the tools are horrible. Well, if you are a developer and want to build something that resembles a typical forms based interface. The tool to use for that at the moment would be the .NET 3.0 SDK with its plug-in support for Visual Studio 2005. It works, sort of but it's incredibly slow, and the XAML editor always runs a split view that can't be turned off with the editor often preview editor and crashing quite frequently often injecting invalid XAML code into the document - that's a lot of fun.

For the above project I actually used the VS.NET Orcas install which was a bit better - the editor is more consistent and a little more responsive, but over all the experience still sucks as royally unresponsive. As you can see the UI above is pretty simple. It's basically a few simple controls and a listbox inside of a Grid container. But even for this simple form that includes a data template for the list display - the list can't be edited or even previewed visually. For most operations in Visual Studio it's actually much easier to work with the XAML directly. Other than dropping controls on the canvas in the first place is easier in most cases. Add to that WPF forms use a custom property editor that doesn't work like the standard property sheet in Visual Studio (similar but subtle differences). For example, you can't choose the grouping of the properties - so you only get the grouped display not an alphabetical list which makes finding the right property a real easter egg hunt <s>. One things that's pretty annoying is that there's no event hookup mechanism through the UI - so you get to do this in XAML and then in code assuming you know what event signature is required.

It's even worse if you want to some layered controls like a menu or toolbar where the layout semantics are quite counter intuitive and the default settings produce something that looks nothing like a standard Windows menu or toolbar.

My feeling here is that if you're thinking you can use WPF to build a form based application chances are that this won't happen easily. It's doable but man does it suck! It's certainly a lot less usable than even the WinForms designer interface which finally in Version 2.0 got to be reasonably usable. The designer story for WPF seems like 5 steps backwards. Hopefully Microsoft will address this but from remarks dropped by Microsoft folks this doesn't sound likely...

There's an alternative for UI design by using Expression Blend and the designer experience with Blend is somewhat better, but it's not really a good fit for a forms based application since Blend clearly has a focus on designer specific layout that is very graphics heavy with gradients and fills front and center above control based layout. Blend is actually quite nice - it's just that it's not a good match for forms based development. As it is I was going back and forth between the VS designer to drop controls, to set properties in Blend and then frequently re-arrange settings in the XAML in VS. A lot of Alt-Tabbing to do even the simplest things. Blend does allow for event hookups and it can work side by side with VS.NET reasonably well - changes made in either environment shows a dialog of a modified file. This isn't optimal but it's workable. Designers will probably work exclusively in Blend and then the process is a lot smoother.

Ok the above UI is very basic and laying out a few lables textboxes and labels isn't too terrible. It's in composition where things are painful. For example, the tab order is determined by the order of layout with no tools to help you reorganize the tab order. You end up having to actually move the controls around in XAML...

Building the List 

The whole point of this form is the list display which gives the opportunity to use WPFs functionality to create lists with rich child content similar to the way ASP.NET lets you created nested controls. This is maybe one of the most appealing features of WPF - the ability to nest just about anything inside of other controls which makes it much easier to create rich control content.

My first pass as this was based on the original code I took from Justin's original code. The original form uses a ListView control and manually embeds the ListViewItems into the list view. So in naivitee I did the same with the WPF code, which actually was a good excercise to go through <s>. Live and learn, right?

private void btnSearch_Click(object sender, RoutedEventArgs e)

{

    this.lstItems.Items.Clear();

 

    this.Cursor = Cursors.Wait;

 

    try

    {

        if (this.txtSearchFor.Text == null)

            throw new Exception("You must specify the text you wish to query for.");

 

        // *** Set up the search object and get the results

        AmazonLookup search = new AmazonLookup();

        AmazonLookup.SearchCriteria searchBy = AmazonLookup.SearchCriteria.Author;

 

        if ( this.radAuthor.IsChecked.Value )

            searchBy = AmazonLookup.SearchCriteria.Author;

        else if (this.radTitle.IsChecked.Value)

            searchBy = AmazonLookup.SearchCriteria.Title;

 

        results = search.SearchForBook(searchBy, this.txtSearchFor.Text);

 

 

        if (results != null)

        {

            foreach (SearchResult result in results)

            {

                ListViewItem item = new ListViewItem();

                item.Tag = result;

 

                item.Margin = new Thickness(10F);

 

                StackPanel outerPanel = new StackPanel();

                outerPanel.Orientation = Orientation.Horizontal;

 

                // *** Wrap in a sizing container

                StackPanel imgCanvas = new StackPanel();

                imgCanvas.Width = 100F;

 

                Image img = new Image();

                BitmapImage imgSource = new BitmapImage(new Uri(result.SmallImageUrl));

                img.Source = imgSource;

 

                imgCanvas.Children.Add(img);

                outerPanel.Children.Add(imgCanvas);

 

                // *** Now deal with the Text blocks

                StackPanel innerPanel = new StackPanel();

                innerPanel.Orientation = Orientation.Vertical;

 

                TextBlock text1 = new TextBlock();                       

                text1.Text = result.Title;

                text1.TextWrapping = TextWrapping.Wrap;

                innerPanel.Children.Add(text1);

 

                text1 = new TextBlock();

                text1.Text = result.Author;

                innerPanel.Children.Add(text1);

 

                outerPanel.Children.Add(innerPanel);

 

                item.Content = outerPanel;

 

                this.lstItems.Items.Add(item);

            }

        }

    }

    finally

    {

        // pointer

        this.Cursor = Cursors.Arrow;

    }

}

This code basically adds new ListViewItem at a time to a ListView control. One thing that was somewhat surprising is that I had to wrap just about everything into its own set of containers. So you above you have a stackpanel to horizontally stack the image and the test section, and then the image wrapped into a fixed width canvas. Then the text block is wrapped into a veritcal stack panel so that the text blocks flow together.

There's a lot of control there for sure but it gets complicated to visualize in code. This reminds me eerily of writing HTML code for tables in code <s>...

The above code works fine, but after I had this working I though WTF: I should be using templates to make this work so this layout can be described as XAML. And that's what I ended up with. However, ending up with the 15 lines or so of XAML took me quite some time <s>...

The final XAML I ended up with looks like this:

<Window

   xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

   xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

   x:Class="LookupListForm.SearchForm"

   Title="Amazon Book Lookup" Height="524" Width="633"

   ShowInTaskbar="False"

   WindowStartupLocation="CenterScreen"

   WindowStyle="SingleBorderWindow"

   FontFamily="Tahoma" FontSize="12" FontStyle="Normal" FontWeight="Normal">

 

    <Grid Name="MasterContainer">      

        <Label Height="26" HorizontalAlignment="Left" Margin="15,7,0,0" Name="lblSearchFor" VerticalAlignment="Top" Width="78.9933333333333">Search for:</Label>

        <TextBox Height="23" Margin="118,10,198,0" Name="txtSearchFor" VerticalAlignment="Top" />

        <RadioButton Height="15.96" GroupName="SearchGroup" HorizontalAlignment="Right" Margin="0,10,73.09,0" VerticalAlignment="Top" Width="81.91" Name="radAuthor">Author</RadioButton>

        <RadioButton Height="15.96" GroupName="SearchGroup" HorizontalAlignment="Right" Margin="0,10,10.09,0" Name="radTitle" VerticalAlignment="Top" Width="56.91" IsChecked="True">Title</RadioButton>

 

        <ListBox Name="lstItems" Margin="0,40,0,40"

                MouseDoubleClick="lstItems_MouseDoubleClick"

                KeyDown="lstItems_KeyDown" >

        <ListBox.ItemTemplate>

        <DataTemplate>

            <StackPanel Orientation="Horizontal" Margin="0,5,0,5">

               <Canvas Width="75" Height="75">

                    <Image Source="{Binding Path=SmallImageUrl}" />

               </Canvas>

               <StackPanel Orientation="Vertical" Margin="5,0,0,0">

               <TextBlock FontWeight="Bold" Text="{Binding Path=Title}" />

               <TextBlock Text="{Binding Path=Author}" />

                   <TextBlock FontSize="10">

                   <TextBlock Text="{Binding Path=Publisher}" />

                   (<TextBlock Text="{Binding Path=PublicationDate}" />)                      

              </TextBlock>

               </StackPanel>

            </StackPanel>

        </DataTemplate>

        </ListBox.ItemTemplate>

        </ListBox>

    <CheckBox Height="23" HorizontalAlignment="Left" Margin="15,0,0,11.04" Name="chkSmallImage" VerticalAlignment="Bottom" Width="141.42">Use small image</CheckBox>

    <Button Height="23" HorizontalAlignment="Right" Margin="0,0,108,11.04" Name="btnSearch" VerticalAlignment="Bottom" Width="75" Click="btnSearch_Click" IsDefault="True">_Search</Button>

    <Button Height="23" HorizontalAlignment="Right" Margin="0,0,22,11.04" VerticalAlignment="Bottom" Width="75" Name="btnCancel" Content="Cancel" Click="btnCancel_Click" IsCancel="True" />

  </Grid>

</Window>

 

I ended up exchanging the ListView for a plain ListBox and then using an ItemTemplate to handle the display, which roughly accomplishes the same thing as the code above did. 15 lines of XAML but it took quite a bit of time to get this right.

One of the things that I really dig about WPF is the databinding support which allows binding to arbitrary objects and collections and map to things like properties (on objects) or data fields (in database fields) or XPATH paths (in XML sources), which is very easy to deal with. However the syntax for bindings takes some getting used to to be sure. In the code above I'm basically binding to the list of SearchResult objects returned by the Amazon service. SearchResult is a plain old CLR object and the collection is merely a generic List<> yet the code above will happily bind the list and fields to individual properties.

With the data template in place the code gets a bit simpler:

private void btnSearch_Click(object sender, RoutedEventArgs e)

{

    this.lstItems.ItemsSource = null;

 

    this.Cursor = Cursors.Wait;

 

    try

    {

        if (this.txtSearchFor.Text == null)

            throw new Exception("You must specify the text you wish to query for.");

 

        // *** Set up the search object and get the results

        AmazonLookup search = new AmazonLookup();

        AmazonLookup.SearchCriteria searchBy = AmazonLookup.SearchCriteria.Author;

 

        if ( this.radAuthor.IsChecked.Value )

            searchBy = AmazonLookup.SearchCriteria.Author;

        else if (this.radTitle.IsChecked.Value)

            searchBy = AmazonLookup.SearchCriteria.Title;

 

        results = search.SearchForBook(searchBy, this.txtSearchFor.Text);

 

        // *** Simply assign to bind

        this.lstItems.ItemsSource = results;

 

   }

    finally

    {

        this.Cursor = Cursors.Arrow;

    }

}

 

This is obviously a bit simpler and clearly is the preferrable approach for being able to modify the UI externally and add functionality without writing any code. But this points at one of the hard parts in WPF - deciding which controls you should actually use for a given task. For example the ListView and ListBox don't have a heck of a lot of difference in functionality other than the databinding mechanism. The same thing goes for trying to figure out which type of panel to use as a container/wrapper around other controls - and so maybe (or maybe not) you can see how it's easy to waste away an hour or so just experimenting with different types of controls.

 

Yeah, but at the same time this sort of template based binding and representation is definitely nice and will likely be more familiar to ASP.NET developers than WinForms developers. If you look at the amount of code (both code and XAML) involved it's very small, although arriving at that small block of XAML takes some, uhm, training or at least time behind the wheel. As with ASP.NET when you start dealing with Markup it often becomes much more difficult to discover functionalty or options available. To implement this form a lot of different approaches could have been used - there's an endless variety possible here.

 

Overall, this was an interesting experience, but it really made me feel like Noob. And it made me think a bit about WPF as well.

 

Where exactly does WPF fit?

So I'm sitting on two small internal applications that I need to build. For a while I was considering using WPF for these little applications, but after going through this experience I'm pretty sure that I won't use it at this time. I had hoped to use these small apps as an opportunity for getting more familiar with WPF and trying to find the advantage of WPF. There are a lot of things to like about WPF no doubt, but for typical business applications I'm hard pressed to really find the need. This form's a good example - while sure WPF makes this list type interface a bit easier, in the amount of time I (ineffectively) spent trying to fumble my way through some of the basics I could have built an owner drawn ListView that does the same thing for a WinForms app. There are a number of subtle nice things in WPF like the ability to work with Web content directly (for example the image in the list is directly bound to a Web based URL - something that takes a bit more work in WinForms for example). So while there are some clear benefits, I don't think that WPF makes a lot of sense for more traditional LOB scenarios until Microsoft (or a third party vendor) steps up and provides better tool support as well as better control support. WPF has a decent set of base controls, but it still minimal. Examples: no date time input controls, no masked edit - all things that finally got decent enough in WinForms 2.0. Part of the reason for this lack of an abundance of controls may also be that creating controls for WPF is probably a lot more difficult than it was for WinForms. The control model is very complex and not only do you have to produce a control but it has to be themable and allow fitting into a style based environment.

 

There are a whole bunch of concepts that never applied to WinForms which is both good and bad. The platform is geared towards truly creative people with design based principles on their mind. Ok I can buy that - we need that too. But where are these design minded people going to spring up all of a sudden? They exist alright, but they speak a different language and they are just as expensive if not more so than developers. Who's going to pay for all this design work?

 

And if you're a small shop or lone developer like me where does that leave you really for stuff you build on your own? I can bushwhack my way throgh this stuff as I have been but I doubt I'll ever produce a shiny rich 'experience' application. Commercial software sold to the mass market certainly will want to take advantage of all this, but the average custom application? Can you really see that?

 

Anyway - I'm curious to see where all this goes, and especially in the even more downturned versions of WPF like Silverlight...

 

So how long did it take? I'll be vague: An entire evening, but either way you look at it - way to damn long Noobishness or no! <s>

Grab the code for this article

Posted in WPF  

The Voices of Reason


 

John Walker
May 15, 2007

# re: WPF Experiments: Changing a Live Writer Plug-in to use WPF

Rick - been reading your blog for some time now. Gotta say that the level at which you code is really phenomenal. Thanks and keep it coming.

DuncanS
May 15, 2007

# re: WPF Experiments: Changing a Live Writer Plug-in to use WPF

"changes made in either environment shows a dialog of a modified file"

Don't know about Blend, but in VS: Tools / Options / Environment / Documents / Auto Load changes...

Steve from Pleasant Hill
May 15, 2007

# re: WPF Experiments: Changing a Live Writer Plug-in to use WPF

Seems like a new hammer looking for a new nail.

The whole development infrastructure needs an overhaul. AJAX is a glorified hack in my opinion, unless you use a solid component, as what is the point in maintaining javascript? Seems to be a step backward.

True, VS type apps are more business oriented and not "artistic", so having a means to do something along those lines whether it be Flash or something else, and somehow use VS type skills would be nice.

Rick Strahl
May 15, 2007

# re: WPF Experiments: Changing a Live Writer Plug-in to use WPF

I'm not sure I can agree with that Steve. I think WPF is in a way that overhaul of at least the Windows Desktop API and it's something that's needed, so it's not what I would think on the frivolous side of things. But on the other hand I really wonder why the execution of the tool side and general consistency of WPF in regards to building less design centric but more form centric applications has been so badly neglected recently at Microsoft. Apparently the focus is different, but it would seem to me that vast majority of developers in the MS camp are not going to have extensive use for any 'design' centric features. Which isn't to say that this functionality isn't needed - Microsoft tools have traditionally lacked this functionality at all so this provides extended functionality that wasn't there before which is important both to expand functinality and bring new ideas into the development fray.

But I think what we really need is technology that unifies the platform in general. WPF seems more of the dividing type of technology where you end up having to make choices. Do I use WinForms (stability and tool support) or WPF (flashy and flexible but horrible tool and forms support). WPF has the capability to work well for all scenarios but it seems WPF is stalled and stuck on the design aspect.

Wouldn't it be nice if you could look at WPF and without a doubt think to yourself, yeah that's the way forward? No such luck... Instead we gotta hee and haw and worry about continuing on with a now discontinued technology stack (WinForms) that won't be updated or working with an immature platform. Which of these sounds more exciting to you? <s>

Steve from Pleasant Hill
May 15, 2007

# re: WPF Experiments: Changing a Live Writer Plug-in to use WPF

Damn! Nice reply. You sound like what I imagine my therapist would be like if I had one. Very patient!

Mat
May 16, 2007

# re: WPF Experiments: Changing a Live Writer Plug-in to use WPF

Thanks Rick, this kind of 'narrative' exploration is gold. It's sometimes more useful to read about problems rather than final solutions. I had to laugh when I first got to:

> ... but after I had this working I though[t] WTF: I should ...

... and I thought "WTF" - what's that? A new MS technology I missed out on! ;)

I remember back in the days of Delphi 1 having to spend time building or extending a few GUI components at a fairly low-level. Before too long though there were components publically or commercially available to make that a thing of the past. Probably WPF will follow a similar pattern.

Josh Stodola
May 21, 2007

# re: WPF Experiments: Changing a Live Writer Plug-in to use WPF

This is a really superb article, I found it to be very useful.

Thanks...

Phil Steel
May 24, 2007

# re: WPF Experiments: Changing a Live Writer Plug-in to use WPF

Great article Rick.

I have a question for you: if the Winforms techonology stack is going to be discontinued have you heard any rumours around MS as to whether they will incorporate all the Winforms 2.0 stuff (like design-time support)?

Winston
May 28, 2007

# re: WPF Experiments: Changing a Live Writer Plug-in to use WPF

Great article!

After a weekend of reading about and playing with WPF to decide whether to use it on a current project, I must say this is the best, most honest critique of WPF I have read.

My biggest concerns at this point are designer support, performance, and interop with WinForms. Just opening a xaml file in VS takes forever, and most of the examples I try to open are unable to be displayed in the designer. I've read everywhere that WPF is supposed to have a more efficient graphics layer that leverages DirectX, but most stuff is dog slow on my machine. Definitely much slower than flash or even java.

WPF is exciting and it's nice to have a flashier option to WinForms, but since it can't effectively replace WinForms, MS really needs to improve the interop.

My wife is a product manager for a software vendor. I showed her the WPF Momentum video and her reaction was "Woohoo. Everything's 3d and animated. So what? It all looks like Flash, and none of it looks like anything I would actually want to use." I feel the same way.
I'd say that for the majority of applications I can conceive of, they would all benefit from some enhanced UI, but none of them would be worth writing in WPF. Not yet, at least.

I'm still confused by the message from MS on WinForms vs WPF. If I had a list of every WinForms app ever written, what portion of those apps does MS now suggest be written in WPF? Or does WPF address a *completely* different set of applications? It seems it does. It seems like WPF was written with Silverlight / Flash competition in mind, rather than the evolution of WinForms.

I'm eager to move past WinForms (or to see it evolve), but I'm going to wait until I see:

1. Someone build a truly usable and performant application (not just a sexy one) in WPF.
2. That person document their efforts with the same candor you did and conclude that WPF was the right choice.

Rick Strahl
May 28, 2007

# re: WPF Experiments: Changing a Live Writer Plug-in to use WPF

Phil - I don't know. Microsoft hasn't really outlined their WPF strategy, but from what I have heard so far, it sounds like the VS.NET integration won't get substantially better than what we see now (hopefully more stable though). As to control support there has been a bunch of discussion on this in and out of Microsoft and it was pushed off for a later date at the time (this was for WPF release). I'm not sure what later means in this context, but I get the feeling this is just not a priority at Microsoft.

Winston - thanks for the thoughts. I think the big issue is that WPF is targeted differently than WinForms. WPF is targeted at commercial consumer applications and high end technical scenarios which is a need that WinForms traditionally has not addressed well. If you search around abit you can find some good examples of this stuff online and for download. Also another pretty good example is Expression Blend which is built with WPF. Blend is actually pretty snappy from a UI perspective so I suppose it's possible to build a speedy UI with WPF.

But it's the LOB scenario that's not been addressed so well in WPF. And the message in this space is mixed. WinForms isn't dead - it's just that there likely won't be any major improvements made to it from Microsoft's end. The platform is in pretty good shape in .NET 2.0 and there's rich third party support so WinForms apps probably have a long live ahead of them without looking dated given that most of Vista doesn't use WPF either. <s>

Rodrigo Groff
January 23, 2008

# re: WPF Experiments: Changing a Live Writer Plug-in to use WPF

If you look at the code to both technlogies, WinForms and WPF, the first has better architecture. Serious programmers dont want to edit XML (or XAML, the same crap) - it become too complex to handle even with small apps as noticed in this article.

Companies, like my own, wont work with WPF. Its WAY better to enhance WinForms with skin methods than accept and work with this crap..

I think this complexity that is reported in your article reflects my opinion on the current state of the industry, read here http://rodrigogroff.page.tl/Home.htm

Thanks for this article!

Groff

Rick Strahl
January 23, 2008

# re: WPF Experiments: Changing a Live Writer Plug-in to use WPF

@Rodrigo - I don't agree. XML as back store for layout is a heck of a lot easier to read and understand than looking at a bit of raw code. Of course that point would be moot if decent deisgners were available, but we're not there yet...

Nevertheless I feel that the XAML portion of WPF is one of the nice features as it allows for easy generation and customization of UI code without having to use source code generation. There are advantages.

The big problem is that right now at least the tools don't do a good job of creating XAML and in effect the WPF object model's complexity and nestability is actually a detriment to the readibility of the XAML code.

Complexity is not necessarily a bad thing. In your article you talk about low level APIs - think about raw Windows apps. At first we wrote them by hand and then eventually frameworks emerged that made the job easier and so much that today hardly anybody still knows how to write a Windows application with a message loop in C++. The same can and probably will happen with WPF, with higher level controls/containers providing a simplification of the model.

Matt Searles
October 20, 2008

# re: WPF Experiments: Changing a Live Writer Plug-in to use WPF

WPF is a strange beast. With a lot less WPF practice than WinForms, you can create a 'richer' user experience much quicker.

I recently started developing almost exclusively with WPF. There's things that you can't believe don't work, or are missing, but once you know what they are, it's not so bad.

I wish I had a screenshot of the project I'm currently working on. It's the first serious WPF app I've worked on, and it looks about 3000% better than what I could have created with WinForms. In fact, it would have been... extremely daunting to create the interface in WinForms. There's lots of gradients, semi-transparent toolwindows, UI databinds and 'fancy' custom menu's/context menus.

I imagine, in regards to UI development, there's almost nothing you couldn't do prettier and faster in WPF than in WinForms. And once WPF has all of the controls you take for granted in WinForms (a fully functional DataGrid for example, which we're STILL waiting on) for example, I think it'll become the default for designing UI's.

It does take a while to come to terms with the sometimes useless designer, lack of databinding debugging support, incomplete XAML intellisense and the new way of describing a UI though.

West Wind  © Rick Strahl, West Wind Technologies, 2005 - 2024