>>Hi,
>>
>>>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 wonder how MS envisages making money on that approach. The more accessible they make web-based apps the less saleable their desktop products become.
>
>Well the Windows division and the developer division are two separate entities and not always in sync. But I think Microsoft is still struggling hard to re-invent itself as a company that can work on the Web and integrate Windows with the Web. Most of this has really gone nowhere to date...
>
>But that's just a common symptom at Microsoft at the moment - they've completely lost their direction. They're going in 50 directions at once without any real focus where it's all heading. Right now for technology it's just: Throw out as much new tech as possible and see what people glom onto.
>
>WPF was a big effort and was well designed until the very end when a lot of the core designers jumped off the ship to move on. And it shows... this seems to be happening a lot these days.
>
>
>>>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.
>
>>Your probably right about XBAP although it might be viable in a corporate intranet environment. The problems you mention all seem to stem from the IE configuration and if that can be controlled ( and I think it can using group policies) it *might* be workable..
>
>Well that plus it requires IE in the first place. The same issues by and large exist with Click Once deployment...
>
>>I don't find the nesting complex (especially if we're talking only of the elements within the ListBox). Looking at it I get a clearer understanding of what's going on than if I had to read (or write) the same thing in procedural code.
>
>Ok, fi you need to do composition this might make sense. But if you just want a quick and dirty list box that doesn't look like crap you still have to go down this sort of path (maybe with a bit less effort).

I'll accept that doing simple things is somewhat simpler in Winforms. But I find doing more complex things is *way* simpler in WPF.

>
>>I suppose one does tend to end up with deep containerships - but the rules governing what you can (or must) do are pretty straightforward. And it's those rules that make things like dependency properties and automatic event bubbling possible and/or useful.
>
>Well, maybe that seems natural to you and is easy for you. But I can tell you it's way more work than say using a listbox and specifying an itemimage.
>
>>>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.
>>
>>I'm afraid I still don't see what you're getting at here. You mentioned earlier that you see developers taking much longer to develop a workable WPF UI compared to a WinForms equivalent. AFAICS there are two elements to any UI - getting controls to (a) appear where and as you wish them to and (b) behave as you want them to.
>>WPF, with it's built in sizing and postioning (plus templating/styling abilities), can do a lot of (a) whereas Winforms would require a *ton* of complex procedural code to achieve the same thing. OTOH If you only want the Winforms functionality in a WPF form then just using the WPF Canvas container has pretty much the same effect.
>
>Well I think the controsl that ship in the box are nowhere as easy to use as they should be. Compare the menu or toolbar controls for example to Winforms and tell me you will create a toolbar or menu as quickly as in WinForms.

Bit like above: designing a Menu system using the Winforms IDE is better and simpler visually (although I have no problem just doing the same thing with XAML). But if you change your mind about something (for example wanting to move a set of sub-items from one branch to another) Winforms is a pain. You either have to delete and re-create them individually in the IDE or scratch around in the Designer.cs file. With WPF it's the work of a moment to cut and paste the whole bunch within the XAML code. And I certainly don't find working with ToolSrips (and ToolStrip containers) in Winforms as easy as the WPF equivalents.

>
>Yes you have way more options with WPF menus/toolbars and what you can do with them, but they are menus and toolbars and 90% of the time behave just like old style toolbars and menus. You pay for the extra functionality that you are not likely to be using.

>
>>As far as behaviour goes I also can't think of a WinForms example that cannot be replicated in WPF with the same, or less, amount of effort - with the obvious exceptions of missing controls such as a data grid that you've already mentioned. I'm sure you can come up with a few things that are easier in WinForms - but I'm also sure I can come up with more that are easier in WPF.
>>Of course I'm assuming equal familiarity with both platforms (on my part this is (a) equal but (b) low <g>). Of course, nothing is impossible in either.
>
>I don't think so. Your skillset to build a decent WPF application has to me at a much higher level than to build a decent WinForms application. You don't need to know about containership, about virtual pixel sizes, about excessive containership relationships and how visual tree hierarchy will effect your exposed events. You do have to understand a lot of crap with WPF about how it works before you can effectively use it. It's a much higher bar for entry.
>
>There's a payoff there sure, but I'm questioning whether the higher bar of entrance is necessary for most developers. In fact, I'd guess that a vast majority of developers just wants to do what htey always did: build forms based applications. So where's the benenfit of WPF there?
>
>>Not sure why you say this. As mentioned below WPF supports the IDataErrorInfo interface which I thought was pretty much the standard to use for validation in WinForms anyway (didn't Lhotka use it in his BOs in CSLA).
>
>Have you tried to do this? It's a fair bit of work to hook up validation. You have to create a handler for everything rather than having a consolidated handler in one place.

Isn't it all in the IDataErrorInfo indexer?

>>I did. The main thing I noticed that was 3.5 added support for the IDataErrorInfo interface (using DataErrorValidationRule rather than ExceptionValidationRule). I guess throwing an exception to enforce validation worked OK but, as many pointed out, it wasn't the sort of thing exceptions should really be used for.
>
>An exception is just the wrong thing to do for validation because in an event driven system; where do you catch that exception? You need events or a central notification in a databinder or similar object.

Well the ExceptionValidation approach relies on exceptions being thrown but using IDataErrorInfo puts all your validation logic in the datasource object and doesn't use exceptions at all. There's no other 'built-in' option in Winforms is there?

>>>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...
>>
>>I guess separation of groups is a bit of a two-edged sword. Group B may pick up on the good ideas of Group A - but may be just as likely to take on board the bad ones as well.
>>
>>>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.
>>
>>Hmmm. Isn't SilverLight just a lightweight XBAP?
>
>No. SilverLight runs cross browser. It's native code in a portable .NET runtime that can run on other platforms (or the Mac at least).

I'd forgotten about the cross-platform capability....

>>I must admit I haven't properly looked at SilverLight - primarily because I'm rarely involved in the visual side of web applications. Actually I don't know if I'm right in the assumption that it primarily a tool for visual enchancements - must explore.
>
>Well, silverlight has an identity crisis too. It's in the same place as Flash - you can build whole applications in Silverlight with XAML and C# code, but that doesn't necessarily mean that that's a good way to go.

>Any binary technology suffers from not really being part of Web content - it can't be searched for example, which is one of the primary premises of many Web applications.

Surely that depends on the type of web site/application - if you're building page content thats driven by changing data there's not much point in it being indexed by search engines since going to the link later wouldn't produce the same results.

>>Anyway perhaps we should come back to this in a few months time. By then, with more experience of WPF, you may have a better opinion of it and I, on the same basis, have a worse one <s>
>
>Not me. I'm done with WPF for the time being. I'll wait until the next major release, until the tools get better and Microsoft or third parties provide a better stock control story. It's too much of a time sink for no real value to the apps I build.
>
>Unless I have a project that truly requires the UI flexiblity that WPF provides. So far I have only had one occasion when that actually was the case (a small graphics utility to create buttons and gradient images for Web apps).

I initially looked at WPF for an app with fairly complex graphic requirements and, so far, it looks good. But although there's a lot of manipulation of graphics objects there aren't too many in use at once (maybe a counple of dozen tops) - and I do have a feeling it might not scale so well if there were, say, several hundred such objects. But I played with the graphics side for a while before I even looked at form design - maybe that's why I found the containership logic easier to grasp.

Anyway I guess we've agreed on the things we're going to agree on and should just agree to disagree on those where we do not <s>

On an unrelated note, whilst writing this I've being trying to remember when I was last in Maui. I know I've been four or five times but the last time must have been in the eighties; maybe even the seventies. I'm sure it's changed a lot since then....

Best,
Viv