Hi All,
I'm coming back after 3 weeks off with a new baby injury, and have read this whole thread with the usual dread. I've been doing nothing but WPF XAML development now for 2.5 years and consider myself a proficient Devign Zombie as SB puts it (I thought I was the only one!). I'll try to cover multiple emails in this post. . Don't even consider using the VS designer. When Blend came out I took the time to learn how it works (by numbing my developer brain with alcohol and letting my design instincts take over). Once you learn how to drive the Blend interface it's actually a very sweet tool. Yes it's buggy as hell, which is why I only use it for standalone test/prototyping. Don't bother pointing it at a real project because it's almost guaranteed not to work. Just start a new project, use it to work out your immediate UI design problem, and then copy the XAML to your real project. Even being proficient in Blend (+ Sketchflow), I find I spend about 50% of my time using the XAML editor (or VS pointed at the same test project) to do my coding. It does a fantastic job of turning drag and drop into XAML, but I still take the time to clean it up by hand. It's an awesome tool for learning about XAML control properties and styles too, and I did learn a lot back about each control from it back in the day. I use it every whenever I'm designing a new window/control and it is why I remain productive. I recommend taking the time to learn using it. [Aside: the upcoming VS designer apparently uses the same code base as Blend (finally) so my opinion of the VS designer may change] . Learning XAML is bloody painful. I think this is the reason why people who have learned the skills have burned it from their memory and don't take the time to help out. It's painful to dredge up the memories of "how I solved this problem with that control in this situation" so I guess we tend to hold our knees to our chest and rock gently when we're reminded of what we actually went through. Every control has quirks, and most of them have many. Learning XAML is all about developing your own approach to solving the problems you come across while doing real work. There are so many ways to solve each problem, but after a while you learn what works for you and develop technique. But it takes many, many, -many- hours of work to get there. And there are so many problems that are similar that require different techniques to solve, but eventually you learn how to spot the most likely ways to resolve problems. . Learn about the Panels first. This is the way you carve up the surface to get your high level layout right. Sketch the layout on paper, and then use your designer to roughly position everything. Blend is awesome here because the design surface is actually running and (almost) always shows you exactly what things look like when you run them. . When you're running, use Snoop to tweak properties to get your layout right. At the same time, load the XAML file in a different editor (notepad, another VS instance) so you can add the mods you're making with Snoop into your code. That way you run you reduce your run / stop / change code / run cycle a lot less. . The biggest AHA moment I had with XAML was realising that when you add properties to converters you can do amazing things. I use converters a hell of a lot to complement the data binding process, and they are an extremely powerful tool. . Behaviours are another really important way to create nice code. Attaching behaviours to elements is a very powerful concept, and you should learn to use it effectively (eventually). I don't wield them anywhere near as converters, but they are very important to have in your arsenal. . I don't use any aspect oriented programming to handle raising property changes. I agree it's a little old school needing to raise property changes, but I want to control when this happens myself, and make some effort to ensure I don't raise property changes willy nilly. I -do- use VS snippets a hell of a lot to be productive at creating code. I also use AutoHotkey to dump out XAML quickly. Don't use resharper (*spit*); VS is bloated enough without adding a tool that replicates 80% of what it does in a different way. And I don't use VS addins that help write XAML. Between snippets, AutoHotkey, and the awesome editing power of VS code editor (and sometimes a bit of Excel to generate large, repetitive chunks of XAML), you can spit out the code you need real quick (even though sometimes there is a lot) . Learn to use #region to organise your view models into appropriate pieces of code. Collapsible code regions are an underrated way of removing clutter while you are writing code. . The main project I'm on is a very large business application and thanks to WPF we can make some really slick stuff relatively simply. Most of the benefits come now that we have our established framework (View generation, messaging system, etc) in place and we can focus on just producing stuff. The project is about 5/6 years old now and we're using a customised version of CAB and it does the job. I'd love to try some recent frameworks (Windsor/Caliburn/Prism/MEF) but at the moment I'm only able to work during business hours. My point is, once you have the big pieces in place you won't have to worry as much about them, leaving your problem solving capacity to dealing purely with XAML quirks and layout. . Don't think about designing uber-cool looking new UI that will have everyone gagging with envy. It was only after years of working at it that I'm now finally able to use what I'm learning to dream about UI like this and implement it. Do the hard yards and learn how to think XAML first, then you will have the capacity and ability to build whatever you can design. . The best way to be productive with XAML is to slow down. Plan your changes; draw sketches, prototype, make comps using Photoshop, do -everything- you can to ensure what you want to build will work before you start coding. Keep these plans available for when you want to change existing UI so you can ensure the changes will work. Once you start coding you'll be spending most of your time solving quirky problems and won't have the capacity to update the design due to issues that arise; do what you can to ensure you know exactly what the UI will look like before you code I wish there was an easy path to learning XAML but I don't think there is. However the very from up here is awesome; I wish everyone could enjoy this as much as I do! Carl. Carl Scarlett Senior .NET/WPF Developer, UX Designer | Genesis IT & Change Management | Bankwest A: Level 5, 199 Hay Street | Perth | Western Australia | 6004 P: (08) 9449 8451 M: 0408 913 870 E: [email protected] Description: test From: [email protected] [mailto:[email protected]] On Behalf Of Kirsten Greed <[email protected]> Sent: Wednesday, 23 November 2011 7:46 AM To: <[email protected]> Subject: Getting up to speed in wpf Hi All I am new to WPF and missing the winforms way of doing things . I am wondering about the best way to get up to speed Do people usually set the data source and drag drop controls onto the designer - or use write XAML - or use Expression Blend - or something else? Pros and Cons? Thanks Kirsten ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ _______________________________________________ ozwpf mailing list [email protected] http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf ________________________________________________________________________ _______ This email has been scanned by the Bankwest Email Security System. ________________________________________________________________________ _______ _______________________________________________________________________________ Unencrypted electronic mail is not secure and may not be authentic. If you have any doubts as to the contents please telephone to confirm. This electronic transmission including any attachments is intended only for those to whom it is addressed. It may contain copyright material or information that is confidential, privileged or exempt from disclosure by law. Any claim to privilege is not waived or lost by reason of mistaken transmission of this information. If you are not the intended recipient you must not distribute or copy this transmission and should please notify the sender. Your costs for doing this will be reimbursed by the sender. We do not accept liability in connection with computer virus, data corruption, delay, interruption, unauthorised access or unauthorised amendment. _______________________________________________________________________________ ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________
<<inline: image001.png>>
_______________________________________________ ozwpf mailing list [email protected] http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf
