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

[Phil J Pearson]

Yes, I agree it's annoying that WPF TextBoxes don't behave by default the way Windows edit controls have behaved since Noah was a lad (by selecting all the text when they get focus). The fact is, however, that it's very easy to achieve this for every TextBox in your application with very little code. This is obviously not a programming question so I won't answer it here. If it was a programming question in the appropriate forum I would say: ... ... just add this somewhere in your app initialisation:

EventManager.RegisterClassHandler(typeof(TextBox), TextBox.GotKeyboardFocusEvent,
new RoutedEventHandler((sender, args) =>
{
(sender as TextBox).SelectAll();
}));

easy-peasy!

Phil

---

The opinions expressed in this post are not necessarily those of the author, especially if you find them impolite, inaccurate or inflammatory.

[Phil Martin]

It's not that bright a side. Swing + JavaFX = lots of fun and actually pretty cool. And the added bonus is JavaFX is way easier to read than XAML.

[Marc Clifton]

Abhinav S wrote:

There are many such bugs in Silverlight too.

I'm not surprised--Silverlight seems like WPF-light, wouldn't there be some sharing of the base code? On the other hand, I'm not surprised for other reasons as well. Marc

[Gary Wheeler]

My 5, and your link is now in my favorites.

Software Zen: delete this;

[Kenneth Kasajian]

You know, I'm not sure it's true that the Windows edit control behaves this way. I recall working with standard USER controls in Win32, and when you select a control, the text wouldn't get highlighted automatically. I had to put the highlighting coding in myself on focus.

ken@kasajian.com / www.kasajian.com

[Patrick Choiniere]

I feel your pain. I'm trying to convert a large winforms app (with visual inheritance used all over) to WPF and I'm nearly bald now from pulling all my hair out. If anyone has any way to do visual inheritance in WPF it would make my job so much easier. As it is I now have to make my code base about 100 times bigger without it. And if anyone asks my boss asked me to convert it. I consider it a total waste of time, but he pays the bills so I'm doing it.

[ExportedNorwegian]

someone desperately need a captcha tool on their blog...

[Adriaan Davel]

A common practice is to show a modal dialog, then set the DialogResult value and close it, which works, except if you show a second modal dialog from the first, the minute you set DialogResult on the first you get an error saying that you can only set DialogResult if you used ShowDialog() :(( VERY frustrating... I have a workaround, but it isn't really pretty...

____________________________________________________________ Be brave little warrior, be VERY brave

[Alan Balkany]

"WPF appears to me to be so much more difficult than it needs to be in almost all aspects." This appears to be a characteristic of Microsoft development software in general. Unless you've done it many times before and know the quirks, doing anything new with a Microsoft development environment often runs into landmines. Things simply don't work, and tasks that should take minutes take hours or days. It's as if they see all other developers as potential competition, and put roadblocks in the way to slow them down.

[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.