Why does so much stuff in WPF not work ? [modified]

[dojohansen]

Just out of curiosity, what are those Java 1.5 sync mechanisms?

[agolddog]

I'm going to ramble a little bit, then ask a serious question (although it doesn't sound serious, I mean it to be--I really don't understand). Christian, I agree with the frustrations of learning WPF. Some of it is fooling around until I have the lightbulb moment, but some seems just inexplicable. Example: I've created a dll with a bunch of core-level domain classes. Nothing to render in that package, strictly business-logic domain objects. This is simply referenced off of a shared drive (or off my local version, if I've been working with it). Next, I've created some user controls in my WPF application. In the same namespace as the app, just in a folder not-ingeniously named "UserControls". When working on the controls, VS renders them just fine. Finally, I add those controls to WPF forms by giving an xml namespace to my app's namespace (like "xmlns:local="appnamespace"), then adding a tag like local:myUserControl .../. The form won't render sometimes, saying it can't load the core dll, or one of its dependencies. This is obviously crap, as a) the control itself can render just fine and b) the application doesn't have any problem reading the dll when getting fired up for testing. I rather suspect it's something to do with rendering the XAML of the control into the XAML of the form, but I haven't been able to figure out why yet. (This morning, I went back to the form and it's rendering fine. Maybe something about forcing VS to lose and reestablish connection to the dll overnight?). /rant OK, now for the question: The people I work with are just in love with forms applications, and I really don't understand it. Why not just build web applications? Instead of having to worry about building an install which ensures that the machine on which my forms app being deployed has all these dependent things, just worry about keeping the web server(s) aligned with development. Why not build an application which is available anywhere on the planet (with a connection) to anyone (with a broswer), instead of limiting yourself to windows-based computers? It seems to me that it's much easier to build and deploy web applications, and there's a lot more knowledge out there how to do that, rather than the specialization of forms apps. Also that anything that can be delivered through forms can be delivered through a browser, so why not take the road that's easier? Or is that just my web background, and things really are easier with forms that I'm not getting?

[dojohansen]

What I don't understand is why the WPF designers don't include support for this *extremely common* behavior out-of-the-box. A simply "AutoSelect" property (bool) would suffice, and then it wouldn't be very important whether it was true or false by default. However, I don't think this is *specifically* the WPF textbox. At least my quick try in Windows Forms and WPF yielded the same result. I used the GotFocus event in WPF and the Enter event in Windows forms, and the event handler simply does this: ((TextBox)sender).SelectAll(); I am not sure why this works perfectly well if you tab to the textboxes, but not at all if you click in them. It seems that clicking inside a textbox clears the selection, which of course is what you want if the box is already focused when the click occurs. And I'm sure if you think about it, in general you *do* want a control, including a textbox, to receive first focus and then the click event if it's clicked in a non-focused state. That would lead to this issue when calling SelectAll in the GotFocus event handler. But all this really boils down to is that it's an all-the-more important oversight not to support this feature directly in the textbox itself, so we simply turn it on!

[M i s t e r L i s t e r]

Isn't that like ALL of MS stuff... ? Get it out the door fast so everybody adopts it... then start working on the next "new big" thing Dropping support for the previous stuff they create.. ?

[Phil Martin]

If you are familiar with reading the Java documentation, here is a good reference[^]. If you aren't, heres a super duper quick summary: Future : A nice representation of the concept "Something that produces a T, but we're not sure when it'll be ready" Sync mechanisms: CountDownLatch - allows one or more threads to wait until a set of operations being performed in other threads completes. CyclicBarrier - allows a set of threads to all wait for each other to reach a common barrier point. Exchanger - two threads can exchange objects. SynchronousQueue - A blocking queue in which each put must wait for a take, and vice versa DelayQueue - a queue of delayed elements, and you can only take from the queue when it's delay has expired. Containers: CopyOnWriteArrayList/Set - A thread-safe variant of ArrayList in which all mutative operations (add, set, and so on) are implemented by making a fresh copy of the underlying array. And it had a whole bunch of thread pooling and task execution niceties. The counter to all of this is "yes, but .Net has, and that and this over here", but the big difference here was that java.util.concurrent was cohesive and really nice to use.

[Hiro_Protagonist_]

Don't know if this is really the case. For about half a year I learned Java/ Eclipse/ Hibernate/ etc. All the tools that are integrated in Microsoft environment are there open source and must be understood. It is no way better. But agreed: There are plenty of things that could be done better. The worst thing is, that MS only does things when they're well known. It could be more innovative :-) Cheers Hiro

[Jason Christian]

I use this code (global style on all TextBoxes) and it seems to work fine.

private static void TextBox_GotFocus(object sender, RoutedEventArgs e)
{
TextBox textBox = sender as TextBox;

        if (textBox != null)
        {
            textBox.SelectAll();
        }
    }

If it isn't obvious, this is attached to the GotFocus event.

[Mike Marynowski]

All you have to do is dispatch the SelectAll() call. Many things in WPF/Silverlight can be solved with a call to the dispatcher and an anonymous function. You definitely don't have to create your own control, we do this on all our login controls. If you really wanted to make it easy, an attached property could be written so that all you have to do in Xaml is add an attribute like ext:Focus.SelectAll="true" to any textbox you like. Attached properties are awesome. Give WPF/Xaml a bit more time and you won't be able to go back to anything else after, it just takes some time to grasp. UI abstractions are very hard, maybe impossible to make simple and powerful at the same time. They attempted to make Silveright "easier" by leaving out things like seperation of keyboard focus and logical focus, removing support for focus scopes. I've found the result is that it becomes difficult to make certain things work the way people are used to. That isn't acceptable for a "native" windows application framework, so there's really no way to have your cake and eat it too. Designing and developing good UI is hard. WinForms was much less flexible than WPF (yey, manual GDI rendering loops), so some complexity is to be expected. As soon as you get over simple things like textbox focus and text selection, WPF makes it incredibly easy to create complex control compositions and custom UI that would be virtually impossible in WinForms (or any other UI framework I've come across).

[BrowniePoints]

So what you're saying is that you should be able to magically understand exactly how to use a huge framework that took a large team at the biggest software company in the world several years to develop without any up front training? Barring that they should have had the clairvoyance to predict every single thing every one of the millions of developers using their tools wanted to do with it and create explicit documentation for them? This is what's wrong with our industry. People expect things to be handed to them on a silver platter. We get paid for our ability to figure out how to do these things. Saying "Unless you've done it many times before..." is akin to saying "Unless someone has practiced playing the guitar, he won't be able to play it well".

[BrowniePoints]

Have you looked at the new Parallel Framework in .NET 4? A lot of what you mentioned is in there now.

[rwinte]

I totally agree with you. We've already submitted one sample application with a focus issue to Microsoft support. Still waiting to hear back on it. We have another outstanding focus issue in our application that I've been messing with for over a year now. I still can't understand some the bugs in WPF even after using it for a few years.

[Fabio Franco]

Flexibility/Power comes at the cost of simplicity. It could've been much better, but these are some things that could've been much better. I'm strugling with WPF myself with things that were really trivial in WinForms. One should ask himself before a projetc: "Is it worth it? Do I need it?"

[bmac]

IMO, a) WinForms give you very precise control over the control-flow if you need it and are willing to spend the time setting it up meticulously. As well, forcing users to install an exe is a measure of security as web-based internet connectivity is necessarily ubiquitous and therefore very difficult to police. b) Browser discrepancies require severely vomitous hackage to overcome the various quirks. Again, security crops up where the power of JavaScript and the DOM combine with the lack of any kind security-oriented browser design planning to make cross-session hijacking preventable only by running each session in a completely different browser -- but that's probably surmountable. c) Performance is naturally way better if any kind of client-side processing is needed and it comes pretty easy via C# or even VB. If you want browser app client-side performance, you have to be a js master or be rocking a gnarlyflop box. And, don't tell anyone, but browser apps will disappear once the dev tools facilitate generating sophisticated patterned software systems (eg: client-server apps with a GUI front-end) -- all the talkytalky is just boilerplate interface mapping and the worst place to do that is in a browser. Why not have a sleek OS-native interface do the UI, where the flow is precise, lightning fast and the net requests can have patterned response semantics? It's the failure of current tooling that makes web apps look like such a good idea -- if you check out MS Lightswitch you will see a hint of what dev sw will facilitate in Web 3.0. I'm not saying WinForms is the ideal here, but it's better than web apps and my dive into WPF left me with the impression of a huge tower of potential whose details are too enormous to define exactly and, thus, implement sensibly. Lots of good ideas in WPF, but having less control doesn't make for reliable/predictable apps. Peace & Blessings, bmac "Lasting peace & happiness for ALL human beings!"

[Alan Balkany]

No: Things don't work as advertised. Error messages are totally misleading. Documentation is wrong or incomplete. Building in .NET recompiles everything, even if no changes were made, and other things waste your time.

[agolddog]

Good and fair points. Thanks for the input. Maybe it's my back-end nature. I'm not really interested in the problems of deployment, UI, or any of those aspects by my nature. I like working on the back-end, in the domain and data layers, and providing services to those who like to work up front. So, when I look at those layers, I think, "why don't we do what seems much easier, and what seems like pretty much everyone knows how to do?" But I think you're right, esp. around the client-side and security points.

[Phil Martin]

Sure have, and it looks great. Combine it with the Rx framework, and it becomes fantastic. The downside is .Net 4 means upgrading to VS2010, which isn't an option right now. Sure there is the version for .Net 3.5, but from what little I understand they are slightly different. I still haven't found a simple equivalent for the CountDownLatch, which is so unbelievably handy. I've written one myself, but I think it's got some nasty bugs in it I haven't found them yet. You can also do it in Rx, but Rx is hugely in flux right now, I can't really use it for production code with any great confidence.

[MarvinMartian]

Well said!

[bara brg2008]

Exactly, people always want things to be made according to there way of thinking, WPF is very flexible not complicated, it's meant to be for the most advanced software, not to the regular use. and thus it required more time and effort to spend on it.

[pg az]

BrowniePoints wrote:

So what you're saying is that you should be able to magically understand exactly how to use a huge framework

Well MAYBE that's what HE is saying. Having never touched WPF even with a 10-foot-pole, I get off the bus at "Huge Framework". Obviously my BS in Physics biased me, I'm always looking for a unified theory with Fewer Axioms that Explain More. CORNER CASES are a huge problem - considering any Instruction Set as an example, you can mix the instructions any way you want and they always work( except for "modern" issues e.g. as discussed by Joe Duffy in "Concurrent Programming on Windows" ) So to me what he seems to be saying is he tried a not-too-strange "corner case", and the primitives did not combine as one would expect. On the other hand I seem to be able to combine MoveTo and LineTo any way I want and they always work as expected...

pg--az

[Frankidoze]

The frustration of learning and finding the solution... 4 me 2 lines of code: private void Popup_Opened(object sender, EventArgs e) { this.myTextBox.Focus(); this.myTextBox.SelectAll(); } This selects the entire predefined text I have in a textbox embedded in a pop-up... And I use MVVM. WPF is awesome...needs lots of research/reading/googling to get it (like anything) but once there...drooling.......

"Nothing is lost, Nothing is created, Everything is transformed" Lavoisier http://wlwilliamsiv.com