>>Aaargh...
>>
>>We just had a 4 hour power outage and I lost my previous rather long reply. Bummer...
>
>Hmmm. Either no UPS in which case the other 3hrs 59mins and 59.9 secs are irrelevant - or you just went surfing for more than four hours. Either way: inexcusable (g)
<g>
Yeah I'm on a laptop so I didn't go down, but while I was working on the box I invariably forgot about the open browser window and closed it. I should have copied the message but I didn't think the power would stay out that long. Lots of power outages here but most are a few minutes. Oh well...
>>Realize I'm trying to be a bit of devils advocate here. I like a lot about WPF but like most of Microsoft's recent technology stack it's short of completion and Microsoft has left WPF to languish since it was released.
>
>I agree. It is odd, given that MS themselves say effort is being directed towards WPF rather than WinForms, that not very much appears to be happening. And if they aren't working on this what are they doing?
I think part of the problem is that the people that took over after Vista released (ie. Scott Guthrie as manager of the developer division) are Web focused. The desktop is secondary to them. I also think they realize that WPF needs just a little more horsepower to be truly viable. I'm sure it'll be the sort of thing we look back at many years from with same view as DOS vs. Windows - lots of folks weren't happy about that either, but now not very many (except the *nix zealots) want to go back to command line computing and terminal windows...
>From that POV we haven't touched on what WPF provides in the way of navigation based windows apps or XAML browser applications. AFAICS what you can do with the latter is only restricted by browser security issues (oh, and the requirement that the browser be IE :-{ )
Well that's a pretty big downside. And XBAP isn't really all it's cracked up to be either even with full security I've had lots of deploy issues. On two machines I lost the ability completely to run XBAP files for no reason I could ever discern.
That'd really cut into your customer base if that happened in a real app <g>...
>>My point in the previous post was this: WPF certainly has cool and useful features and it gives a lot of power to developers. Frankly I think it gives you too much power - or put another way requires you to use too much of that low level power all the time in that it gets in the way of the process you should be focused on which is building a functional application.
>>
>>WPF to me is clearly a V 1.0 product that has some growing up to do. No doubt people will do brilliant stuff with - heck people did more than brilliant stuff with the fatally crippled Silverlight 1.1 alpha, but that doesn't mean that it makes sense for a wide range of developers.
>>
>>The developers that I know that are using WPF are taking a LOOOONG time to build application UIs and even those developers well versed in UI design and comfortable with the design metaphors that WPF emphasizes will tell you that building a decent looking UI with WPF is time consuming.
>
>In the link below you produced an effective listbox using 15 lines of XAML (including databinding). You say it took you a long time. But it was the first time. How long would it take you next time?
Assuming for a second that I hadn't written this up and I couldn't look it up again - it'd take me the same amount of time because there are too many details for me to remember. But even with the crutch it would take a while - I'd have to review the code first again to remember WTF I did. Look at the freaking nesting required to make this happen.
>
>>I shudder to think what the average developer that manages to build horribly mismatch WinForms application will manage to 'accomplish' with WPF <g>...
>
>You mentioned this before and I replied to it in the last post. What's the alternative? Not making tools available in case someone mis-uses them? Bit like saying paint manufacturers shouldn't produce purple paint in case bad interior designers buy pots of it. Of course I could also say it's a bit like putting enriched uranium on supermarket shelves but the analogy isn't so close :=}
Not exactly. THere's nothing wrong with low level tools and interfaces and giving people the power to twiddle if necesary. The problem is that you *have to* use a lot of low level code to simple thing even in high level applications to make WPF work properly. What's missing is a higher level of abstraction that provides the common and core features more accessibly in a more reusable fashion. This is by no means a trivial task which is why I think third party vendors are just now finally *starting* to come out with WPF controls.
>OK, I see it in the screen shot. I also see it in my own setup - but for some reason it doesn't appear to be as pronounced except at small font sizes. I also don't think it's *that* bad. I *do* think text measuring methods are poor in WPF - I want to know if a given piece of text will fit in a given area not to be fobbed off with an ellipsis....(no pun intended)
>
>>
http://www.west-wind.com/weblog/posts/71214.aspx>Thanks for the link. That, and your reply above, comes across as a much less biased critique of WPF than your previous post in this thread.
>
>End of the day, I have to say there's a lot that I like in WPF. I like the consistency that I see in the way the class hierarchy is designed and the consistency in the behaviour of controls in general. I like routed events, I like dependency properties, I like the concept of logical/visual trees, I like ....
>
>Sure MS has work to do. But I think they've started from a good base - just hope they carry it forward.
Yes I agree. I think there's lots of good stuff there. But it worries me that after a year and half we've seen - stagnation. Nothing really new, no improvements not even additions of controls. Nothing. I think they did some perf improvements in the engine, but from an API perspective there were very, very little changes.
>Anyway, on a specific note: What do you perceive as the shortcomings of using Binding ValidationRules? I admit that I haven't used them in anger but from what I've read it looks good....
The problem with Validation is a) that it's a bitch to set up - you need to hook events for all validations explicitly. And b) and this is the real bummer is that validation fires AFTER an item has been updated back into its data source. So unless you saved the value you're updating first somewhere te original value is lost. This doesn't sound like a big deal but what that means is that your validation code has to track original values which is difficult because there's no way to store it effectively and results in duplication. WPF has the mechanisms but the firing order is juts screwed up. There are ways around this but they're all pretty ugly.
To be honest I haven't checked this out in the latest version. I heard there was supposed to be something done about Validation to make it easier, but I'm not sure if this particular issue was addressed. If you search Google for Validation and WPF I'm sure you'll dig up a few posts that describe this and a few other problems.
It's another case where the WPF folks worked in isolation from other teams at Microsoft that have been down this path and made those same design mistakes. WinForms 1.x for example <g>... The WinForms 2.0 DataBinding Controls deal with this properly now but after a lot of back and forth with developers during the LOOONG beta. Totally lost on the WPF folks...
Sometimes it's frustrating being on a little on the inside and seeing crap like this happen. Somebody at Microsoft filnally gets it right and another group reinvents the same thing again - wrong making the same mistakes again...
so it goes...
We'll see. I think there's a good chance WPF will get a big boost with Silverlight. I think the interesting story isn't on the desktop but with Silverlight on the Web. That's really where the UI shortcoming is not on the desktop.
Silverlight already has way more interest than WPF ever had and while it's way trimmed down from WPF's feature set it uses XAML and the same basic object model so lots of people get introduced to WPFs features. The big question is whether Silverlight will catch the market beyond just developers...
+++ Rick ---
>
>Best,
>Viv
>
>
>>>Hi,
>>>PMJI, but looks like fun.
>>>
>>>>>- Takes advantage of video processors to render, so it's faster than WinForms (Hardware acceleration)
>>>>
>>>>It's a myth!
>>>>
>>>>If you've ever built a WPF application you know it sucks a** when it comes to performance.
>>>
>>>Have, and don't. Slower - yes, 'sucks' - no. But I think a lot of our perception of 'slowness' reflects the time we spend in the development environment. I don't think there's any reason why a WPF application should be perceptable slower from an end user POV.
>>>
>>>>Yeah hardware acceleration is there, but it gets lost in the myriad of UI objects that need to be managed. This might change in the future but right now - perf is no reason.
>>>>
>>>>Hardware acceleration only helps with the rendering and shading and vector sizing. IT does nothing for page composition and layout where the CPU still is needed and there are much more objects involved at the .NET level (ie. rather high level code) than in Winforms which is basically calling low level Windows API semantics to render.
>>>>
>>>
>>>The benefits of hardware acceleration are surely going to depend on the Rendering Tier supported by the hardware. In general, with no acceleration, WPF might be slower, but with full support, maybe a lot faster. In WinForms it just isn't going to make any difference period.
>>>
>>>>>- Everything is a vector graphic, so even when scaling, you don't get jagged edges
>>>>
>>>>Depends on what you're using. If you're building all your artwork using vectors yes. But if you're using images you still have to deal with scaling and distortion.
>>>
>>>You get the benefit when using WPF controls themselves.
>>>
>>>>And building scalable UIs is actually quite difficult even when you have anchors and docking available.
>>>
>>>Difficult compared to doing the same thing in WinForms?
>>>
>>>>Frankly if you build any sort of text application with WPF (other than the full scale text viewer) I've found that it really is horrible because WPF uses some odd variation on clear type that makes font display horribly blurry. this is especially noticable if you run on a machine that has clear type off and you see a WinForms (or any other WinApi app) in comparison to a WPF app side by side. It looks awful and blurry...
>>>
>>>Haven't noticed this personally. But on the subject of Text what about the functionality provided by FlowDocument/FixedDocument/XPS?
>>>
>>>>>- You can use UIs that are difficult or impossible with WinForms (Rich composition and customization)
>>>>
>>>>That's definitely true, but you have to know what you're doing.
>>>>
>>>>But you can also turn this around: You can't easily do things that you can do in WinForms with WPF. Possible yes, but because there's a severe lack of controls (even from 3rd party vendors) you don't get many features that you'd take for granted in a forms application.
>>>
>>>I'd say 'a few features' rather than 'many features'
>>>>No date picker, no grid, no masked input, etc. etc.
>>>
>>>WPF has a Grid control ;=}. But yes, you've picked three of the bigger ommissions. Regarding 'severe lack of controls': I just did a quick count - WPF has 57 UI related objects in the default Toolbox, WinForms has 35....
>>>
>>>>Most of the things you take for granted in WinForms are difficult to do with WPF. And creating custom controls is not easy either at least if you want to build a real WPF style control that supports styling and theming.
>>>
>>>>I'll just swap two words in the above paragraph: Most of the things you take for granted in WPF are difficult to do with WinForms. And creating custom controls is not easy either at least if you want to build a real WPF style control that supports styling and theming.
>>>
>>>>>- True separation of behavior from UI elements because of Declarative Programming
>>>>
>>>>>- Data binding better than WinForms
>>>>
>>>>This is one of the highlights of WPF for sure. The databinding and whole Dependency Property mechanisms are great.
>>>>
>>>>Unfortunately there are also serious issues with Data Validation (no way to detect validation errors BEFORE the data is updated back into the data bound source).
>>>
>>>Binding Validation seems pretty flexible and comprehensive to me. What do you think is lacking?
>>>
>>>>>- Microsoft is not using resources to further develop WinForms. All new work is being done on WPF
>>>>
>>>>That's not exactly a big deal given that most of the innovation in this space has always come from third party vendors.
>>>>
>>>Sounds like the VFP/.Net arugment (g,d&r from certain parties)
>>>
>>>>WPF is cool and you can built some really interesting stuff with it, but don't expect to do even simple things in anything less than half a life time <g>... It's incredibly tedious to build even the simplest things that actually look nice.
>>>
>>>Just plain don't agree with anything after the first comma (but, of course, beauty is in the eye of the beholder :-}
>>>
>>>>I don't even want to think what kind of UI nightmares folks who are not versed with graphics design (ie. most of us) are going to create with this technology. It's like giving people Photoshop to design a user interface and saying - have at it.
>>>
>>>I've never quite accepted the argument that you shouldn't give something to someone on the basis that they may mis-use it.....
>>>
>>>>The way I see it WPF is a very shiny new toy that addresses a very specific market segment. It's not a tool - for now - for the Line of Business market. It's a tool for graphically rich application that require heavy visual interaction - typically bubbly consumer applications or graphically rich applications that do advanced graphing/charting or data manipulation using new UI implementations.
>>>>
>>>>There will be people building incredibly mind blowing apps with WPF, but at the same time you have to realize that most of those apps will be designed by designers who understand graphic design. For the average developer doing quality WPF design and layout is going to be a struggle...
>>>>
>>>>I've seen a few WPF apps that are trying to do 'basic' forms interfaces and it's not impressive in anyway. And it took the developers a heck of a long time to make that actually happen... the same apps in WinForms would have taken half the time.
>>>>
>>>>WPF is useful if you have a right application for it. But otherwise it's one of those technologies one should think about very hard before jumping into - unless you have an employer or client that's willing to foot the bill for you to experiement a lot.
>>>
>>>Even for straightforward applications I still prefer the UI controls from WPF. There's a cleaner, more standard, structure to the class hierarchies - by comparison the Winforms controls seem a bit of a hodge-podge.
>>>
>>>Footnote: I'm not really a WPF evangelist. Just thought an entrenched discussion re: WPF v WinForms would make a change from the .NET/VFP variety (g)
>>>Regards,
>>>Viv
>>>
>>>
>>>
>>>>+++ Rick ---
>>>>
>>>>>
>>>>>
>>>>>>During a recent discussion of WPF and the possibility of using it in our applications the topic of what business benefits this new technology provides came up. We are a shop that has several small development teams creating and maintaining windows desktop applications. The applications we develop are not web enabled. We do not and will not have “designers” on staff.
>>>>>> I can see plenty of negative expense in using this new technology but was unable to point to a single benefit.
>>>>>>
>>>>>>Are there any tangible benefits to using WPF beyond have a cool toolbar or button?
