I currently do all development work in VB.NET 2008, winforms; but within 18 months will be switching to WPF (for better or worse). I have had great success using Matthew MacDonald's "Pro .NET 2.0 Windows Forms and Custom Controls in VB 2005" book. This is an excellent reference focused entirely on the development of custom controls in windows forms. ( Many of the controls that I use have to have a very specific UI look and feel, so they end up being custom. )
I'm looking for pretty much the exact same thing, except focused on WPF.
MacDonald has a new book coming out on WPF in general ,but not on custom controls.
Books are my preferred reference material, but any good web references would also be appreciated.
Any suggestions?
I have Pro WPF with C# 2008 by MacDonald and it is a surprisingly good reference on controls, templating, and styling. At over 1,000 pages it is a really meaty work; you can rest assured there is enough material on controls. There are no books dedicated entirely to WPF controls (that I know of) simply because control development in WPF is that much easier than control development in WinForms. If you have a mastery of templates and styles, you can do so much with the basic controls that there is almost no need for custom controls.
Related
Not sure if this an appropriate forum for this, but I need some guidance from those who are further down the road than I am with WPF.
I've used Telerik Winform controls for a years and have mixed feelings about them. They look good, but they are deeply nested, have a steep learning curve, and sometimes don't perform the best. For example, just working with a RadWindow in the WPF designer, it's slow compared with native wpf controls.
I like Caliburn.Micro MVVM framework and MahApps metro styles, but to keep the same look and feel for a ribbon bar I'd need to use another third party tool (like Fluent) or just use the Microsoft Ribbon View control and figure out how to use templates and styles myself (or find an existing metro template for it).
I tried to combine Telerik and Caliburn but had trouble getting them to work. There is a Caliburn Telerik library but its based on Caliburn Micro 1.5.2 and I'm trying to use Caliburn.Micro 2.0.2. Problem is I always get an aero-looking full window title bar and frame wrapped around the Telerik styled window.
I just don't know enough about conventions and such to make it all work together. And frankly, not sure it's worth the trouble. I'm looking for a more streamlined approach that lessens my dependence on pricy and heavy third party controls.
So, I'm looking for guidance on whether I should use straight Telerik, straight caliburn or go through the work of trying to get them to work together.
What I would prefer is to use Caliburn as the mvvm framework with a layer of styling, like what MahhAps provides. And for those controls that aren't styled, like the Ribbon Bar, to either use Microsoft's ribbon bar and find templates and styles that would work or maybe a 3rd party control like Fluent. But would I be getting in over my head in trying to learn templates and styles?
Sorry for the ramble, but I'm frustrated and need some help in working through this. Thanks.
I found a great resource that maybe others new to WPF and struggling with similar questions would benefit from: MarkPad, a Code52 project on CodePlex.
It's written in WPF using Caliburn Micro MVVM framework (although it's version 1.5.2 rather than the current 2.0) and MahApps metro styles with some "roll your own" windows. It's a great looking app with the kind of simple menuing system I was looking for AND an MDI implementation. It's also a good example on how to organize a somewhat complex WPF application, something I was also unsure about.
It answers the question: Do I need to use Telerik? The answer is a definite NO. It's a great learning tool for me and maybe will be useful to others.
Which technology (WPF or Winforms) should be used if UI supposed to be highly customizable like controls layout/design could be change by user and such sort of UI customization.
Kindly mention best practices along to achieve that...
I just recently developed a designer in both WinForms (company req) and WPF (to see how much better it was). WPF has a definate edge, especially when it comes to nicer looking controls and control transparency.
This was my first actual WPF project, other than just messing around, so I was learning as I went. I found this series on creating a diagram designer very helpful. I didn't really do the same things that this article talks about, but more of a hybrid between that and my WinForms app.
I have to admit that the UI functionality was up and running much faster in the WPF version than with the WinForms version.
WPF I have found the easiest to create controls on a fly. Because I can just attach them as child controls to the parent, and the Grids, Dock Panels, just make life easier.
I found WinForms to be clunky to always work with. However I come from a Web background and Xaml makes sense to me.
WPF controls are design and lookless. That means you have a default view of them, but everything detail of a WPF control can be overridden. It's almost akin to using CSS. In the WPF world, you do not create custom controls like you do in WinForms. The main thing in WPF world is "styling" controls and defining a style for them. It just happens that the style also controls the layout and the form of the controls.
WPF is FAR superior for designing and style of UI. Check out these two top WPF companies and tell me if this stuff is easy to do in WinForms:
Cynergy Systems: http://www.cynergysystems.com/
Thirteen23: http://www.thirteen23.com/
I am very confused about WPF and Windows Forms. What is the usage of WPF over Windows Forms?
What is the usage of WPF?
WPF is a new platform for developing applications for Windows (and for browsers). WPF is not necessarily there to replace Windows Forms. With WPF, it is easier to add 3D, video, and animations to your application. Because it is XAML based, it is also easy to bind to XML data, for example, data from a webservice, and dynamically load it as content.
WPF also, in my opinion, better seperates the UI programming from the business logic. It is easier to have an advanced WPF designer build your UI with a tool like Expression Blend, and yourself as a programmer, focus more on the back-end. In that way, it is more like having an HTML and CSS frontender creating a slick design for your site, while you work on the back-end.
Windows Forms has (as for now) more third-party controls available though, and if you don't really have a need for the stuff that WPF brings, then you certainly don't have to switch to WPF.
Have you seen WPF or WinForms, choose wisely ?
In short, WPF is the next UI platform for Microsoft Windows. It learns a lot of lessons from previous technologies, but the risk is immaturity of tooling and third-party components.
One benefit is the separation of concerns. You can build your application without worrying too much about UI stuff like layout, colours, fonts, etc. Then you can pass it to a designer who can make it look amazing (hopefully) without needing to understand code (using Blend or some other tool).
From a purely pragmatic point of view, my choice of which framework to employ is often down to which third-party controls I need to use (although you can use a WPF control in a WinForms app, for example - using hosting controls).
One more thing I like about WPF is that the core graphics processing has been shifted from GDI+ to DirectX. That makes a huge performance benefit when you are working on 3D or heavy grid/time series plotters as it tries to consume your GPU (graphical) resources rather than CPU.
I just installed visio, and the installer almost seemed like it was built in flash.
The buttons kinda glowed when I hovered over them, and when I clicked on 'continue' the form phased out in a cool way.
I'm assuming it was built in WPF.
Anyhow, so are WPF more flash-like (visually speaking).
Do they have new properties where you can make forms phase out nicely/smoothly compared to winforms?
Disclaimer: I work for Microsoft. However, I don't work on Visio, WPF, CLR or Silverlight team. So, the following is my personal take on these technologies. If you want to quote me, don't do it implying it's the official Microsoft position. :-))
Update: Anything I say below about Flash/Flex/AIR might be wrong, as I have not worked with these technologies and what I know about them is based on what I read on the intertubes. :-) If you notice anything wrong, just shout in the comment and I'll correct it.
To the best of my knowledge, the Visio installer is not built with WPF. It's all unmanaged code; it's just people took a lot of care to make it really polished.
WPF is the new UI platform for building standalone applications for the Windows OS. It supports a declarative UI language - XAML, and related CLR types to program against. WPF is a different platform than WinForms, although it is possible to build applications that mix UI built with both. WPF supports a lot of things that WinForms does not, like bitmap effects, animations, control styling and so on and exposes them both in XAML or through code. Also, WPF relies heavily on vector graphics, as opposed to the pixel graphics in WinForms. In short, WPF is quite powerfull and allows building very snazzy UI. (Don't take my word for it, though, as I am biased; go check around for what people are saying about it or buiding with it. :-))
WPF and WinForms do not compete with Flash/Flex. WPF and WinForms are both UI frameworks for building standalone client applications. As far as I know, Flash/Flex are frameworks for building rich internet applications - RIA (though lately people started interpreting this abbreviation as rich interactive applications).
Adobe did come up with AIR about half a year (or maybe a year) ago, which allows building standalone client applications, so you could say that Adobe is trying to position Flash/Flex/AIR to compete with WPF. Of course, that's my take on it and I doubt Adobe's official positiong is anything like that.
If you want to compare particular MS technnologies with Flash/Flex, take a look at Silverlight - it's the MS RIA platform.
Silverlight is related to WPF in the sense that they share XAML and the corresponding CLR types. Silverlight supports only a subset of what WPF offers, though, as it is not targeting Windows OS only and thus is limited by the fact that it has to be portable.
Quick update to reflect the changes in the year since I've written the answer :-)
With Silverlight 3 shipped, SL and WPF are getting even closer and sharing bigger set of supported features. In addition, most of the new XAML controls are built for platform at the same time. Thus, SL/WPF are getting to a point of singularity...
Also, SL 3 supports out-of-browser applications. In that sense, SL is not only starting to compete with Flash/Flex, but it is also encroaching on AIR's turf.
And no, I still don't work on the WPF or Silverlight team. :-)
WPF is being used as a replacement for WinForms, and as a competitor to Flash in the form of Silverlight. WPF consists of an entirely new object model that sits on top of DirectX (at least the desktop version). You can create WPF windows, controls, etc, entirely using C# or another .Net language just like you can render WinForms. However, Microsoft has also created a markup language called XAML (eXensible Application Markup Language). Nodes in an XAML document (XML) map to objects in a similar fashion to the way ASP.Net maps to web controls. XAML typically exists in a .Net project alongside a code-behind style C# file (or VB.Net or whatever). The C# file interacts with the objects generated by the XAML. This is fairly consistent with the "graphics via markup, logic via code" model that Microsoft and others are pushing.
One of the overlooked features when discussing WPF is the completely awesome data-binding that Microsoft wrote for WPF. The new data binding framework is a quantum leap beyond Windows Forms 2.0 data-binding. Microsoft added a couple of new interfaces that make it much easier to make an object or collection emit data-biding events properly. They also provided a very rich set of data-binding classes. You can bind anything to just about anything else. You can bind one-way data to control, control to data, two-way control to data and back, control to control, etc.
Back on the graphics side of the house, WPF makes it fairly easy to make an existing control look like anything. WP lets you compose your own template for what a class of buttons should look like, or one button, or all buttons. Or radio buttons. Or labels. You get my drift. Imagine if CSS included the ability to define what an input button would look like using other HTML controls.
They also provide a number of layout controls. You can continue to use exact positioning like in WinForms, or you can leverage of variety of techniques to make your window act more like a web page that grows and shrinks with resizing, etc.
The downsides: It is too easy to create spectacular effects that crawl on slower machines. Some of the graphics do not take advantage of hardware of graphics cards, though Microsoft has incrementally improved support for this. I believe when 3.0 first came out drop shadows were rendered purely using software. I think 3.5 or 3.5 SP1 changed it so that WPF would utilize graphics hardware for the task. Microsoft has said they will continue to enhance WPF in this fashion.
WPF is .Net 3.0 and above, which runs on XP SP2, Vista, and Servers 03 & 08. So don't plan on deploying WPF to a customer with Win2k desktops.
Summary: If you are doing desktop programming in .Net, you should be doing it in WPF unless you are targeting Win2k. You can avoid the downsides of WPF, and there are many upsides. Microsoft will probably throw away WinForms in some future release, or at very least you will stop seeing new features, etc.
As far as Silverlight goes, the betas for SL 2.0 look good. I think that Silverlight will require some wide-spread adoption. Microsoft has already tried to get this going. The NBC Olypmics site used Silverlight, and Major League Baseball uses it for its MLB.tv product. As soon as Silverlight gets a good install base I think you will see the Microsoft side of the development world starting swinging away from Flash and to Silverlight.
Edit after using Silverlight 3 and MVVM:
I have moved away from WPF and am doing a lot of Silverlight 3 development. But I think my comments here will still apply to the WPF developer.
I have been using the MVVM pattern in my app (think MVC with a twist). The Microsoft Patterns and Practices team has released a set of libraries known as Prism that supports various aspects of MVVM. There are WPF and Silverlight versions. Take a look at MVVM and Prism if you are going to be doing WPF or Silverlight development.
You can do a lot of flash w/ Winforms, or with custom components. But if you want out-of-the-box bang-whizz availability, WPF is the way to go.
Yeah, I think the intention is to be flash-like, it seems to me that MS has set its sights on taking down Adobe.
The way I see it: WPF is to Flash as WinForms is to Flex. WPF has more emphasis on vectors and states than on programming.
Can both WPF and Windows forms controls be used within one application? How difficult or practical an idea is this?
It is fairly straightforward to host WPF controls in a WinForms app with an ElementHost adapter or WinForms controls in a WPF app with a WindowsFormsHost adapter. There are not too many resources on the web showing how to do either of these, however. In the process of learning how to do this for myself I quickly discovered the inherent symmetries between the two pathways. I distilled all my notes into an article comparing and contrasting these symmetries using a unique approach: the article is really two side-by-side articles, comparing every step in detail, starting from creating a user control in one technology to hosting it in an application in the "opposite" technology. My article, published on SimpleTalk.com in August 2010 is available here: Mixing WPF and WinForms.
For completeness, here are a couple good MSDN references, one for each pathway. In fact, the demo solution accompanying my article started from both of these:
Hosting a Windows Forms Composite Control in WPF
Hosting a WPF Control in Windows Forms
I believe there is a WindowsFormsHost control you can put in your WPF apps which will do interop back to WinForms code:
http://blogs.msdn.com/ivo_manolov/archive/2007/07/26/wpf-win32-interop-part-1-hosting-winforms-controls-in-wpf-windows.aspx
We hosted significantly complex WPF controls in an existing LOB WinForms app. It can be done, but we did have issues (some no doubt caused by the steep learning curve). These primarily had to do with loss-of-focus events not being fired when expected, and also keyboard navigation issues.
You can also use an HWNDSource and HWNDHost controls to embed WPF controls in a WinForms (or any Win32, really) app.
When hosting non-WPF content (Be it HTML, WinForms, or Win32 content), you will haveAirspace issues. This means you can't completely compost the WPF content with the hosted content. You also can't animate it etc. There are some interesting issues with respect to scrollviewers see here for more details and a fix also.
Yes you can, both Windows Forms within a WPF application, and WPF controls within Windows Forms. www.novamind.com's mind-mapping application is a successful mix of the two technologies.