Why does so much stuff in WPF not work ? [modified]
-
All I want is, when I click on a text box, the text is all selected so the user just has to type to wipe it. All the xxx events do not work, only the Previewxxx events get called. Still not sure why. I tried PreviewGotFocus. The text gets focused, then when I lift the mouse, the focus is lost. I don't handle any other events on these controls. So I handle PreviewMouseUp. This seems to work, but there appears to be a bug in WPF. If I call SelectAll() on the control, it toggles, if I click on a control, then click on another, then click back, it DESELECTS all. So, I tried adding code to clear the selection first, makes no difference. Then I added code to manually set the selection. This works, BUT, now when I have selected the text, the app will take no more mouse input until I focus on another window, then focus back. I added code to set the focus to the control, this makes no difference. This mess is what I have now, and it still does not work. private void ProcessMouseUp(object sender, MouseButtonEventArgs e) { TextBox tb = sender as TextBox; if (tb != null) { tb.Select(0, 0); tb.SelectAll(); tb.SelectedText = tb.Text; tb.Focus(); } } I googled it and found a class that does what I want. Yes, you have to write your own control to do this. I wasn't asking for help anyhow, my question remains, why is this so complicated ? Why is it so buggy ?
Christian Graus Driven to the arms of OSX by Vista. Read my blog to find out how I've worked around bugs in Microsoft tools and frameworks.
modified on Monday, September 20, 2010 7:51 PM
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.. ?
-
Just out of curiosity, what are those Java 1.5 sync mechanisms?
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.
-
"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.
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
-
All I want is, when I click on a text box, the text is all selected so the user just has to type to wipe it. All the xxx events do not work, only the Previewxxx events get called. Still not sure why. I tried PreviewGotFocus. The text gets focused, then when I lift the mouse, the focus is lost. I don't handle any other events on these controls. So I handle PreviewMouseUp. This seems to work, but there appears to be a bug in WPF. If I call SelectAll() on the control, it toggles, if I click on a control, then click on another, then click back, it DESELECTS all. So, I tried adding code to clear the selection first, makes no difference. Then I added code to manually set the selection. This works, BUT, now when I have selected the text, the app will take no more mouse input until I focus on another window, then focus back. I added code to set the focus to the control, this makes no difference. This mess is what I have now, and it still does not work. private void ProcessMouseUp(object sender, MouseButtonEventArgs e) { TextBox tb = sender as TextBox; if (tb != null) { tb.Select(0, 0); tb.SelectAll(); tb.SelectedText = tb.Text; tb.Focus(); } } I googled it and found a class that does what I want. Yes, you have to write your own control to do this. I wasn't asking for help anyhow, my question remains, why is this so complicated ? Why is it so buggy ?
Christian Graus Driven to the arms of OSX by Vista. Read my blog to find out how I've worked around bugs in Microsoft tools and frameworks.
modified on Monday, September 20, 2010 7:51 PM
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.
-
All I want is, when I click on a text box, the text is all selected so the user just has to type to wipe it. All the xxx events do not work, only the Previewxxx events get called. Still not sure why. I tried PreviewGotFocus. The text gets focused, then when I lift the mouse, the focus is lost. I don't handle any other events on these controls. So I handle PreviewMouseUp. This seems to work, but there appears to be a bug in WPF. If I call SelectAll() on the control, it toggles, if I click on a control, then click on another, then click back, it DESELECTS all. So, I tried adding code to clear the selection first, makes no difference. Then I added code to manually set the selection. This works, BUT, now when I have selected the text, the app will take no more mouse input until I focus on another window, then focus back. I added code to set the focus to the control, this makes no difference. This mess is what I have now, and it still does not work. private void ProcessMouseUp(object sender, MouseButtonEventArgs e) { TextBox tb = sender as TextBox; if (tb != null) { tb.Select(0, 0); tb.SelectAll(); tb.SelectedText = tb.Text; tb.Focus(); } } I googled it and found a class that does what I want. Yes, you have to write your own control to do this. I wasn't asking for help anyhow, my question remains, why is this so complicated ? Why is it so buggy ?
Christian Graus Driven to the arms of OSX by Vista. Read my blog to find out how I've worked around bugs in Microsoft tools and frameworks.
modified on Monday, September 20, 2010 7:51 PM
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).
-
"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.
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".
-
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.
Have you looked at the new Parallel Framework in .NET 4? A lot of what you mentioned is in there now.
-
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.
-
All I want is, when I click on a text box, the text is all selected so the user just has to type to wipe it. All the xxx events do not work, only the Previewxxx events get called. Still not sure why. I tried PreviewGotFocus. The text gets focused, then when I lift the mouse, the focus is lost. I don't handle any other events on these controls. So I handle PreviewMouseUp. This seems to work, but there appears to be a bug in WPF. If I call SelectAll() on the control, it toggles, if I click on a control, then click on another, then click back, it DESELECTS all. So, I tried adding code to clear the selection first, makes no difference. Then I added code to manually set the selection. This works, BUT, now when I have selected the text, the app will take no more mouse input until I focus on another window, then focus back. I added code to set the focus to the control, this makes no difference. This mess is what I have now, and it still does not work. private void ProcessMouseUp(object sender, MouseButtonEventArgs e) { TextBox tb = sender as TextBox; if (tb != null) { tb.Select(0, 0); tb.SelectAll(); tb.SelectedText = tb.Text; tb.Focus(); } } I googled it and found a class that does what I want. Yes, you have to write your own control to do this. I wasn't asking for help anyhow, my question remains, why is this so complicated ? Why is it so buggy ?
Christian Graus Driven to the arms of OSX by Vista. Read my blog to find out how I've worked around bugs in Microsoft tools and frameworks.
modified on Monday, September 20, 2010 7:51 PM
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?"
-
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?
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!"
-
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".
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.
-
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!"
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.
-
Have you looked at the new Parallel Framework in .NET 4? A lot of what you mentioned is in there now.
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.
-
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".
Well said!
-
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".
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.
-
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 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
-
All I want is, when I click on a text box, the text is all selected so the user just has to type to wipe it. All the xxx events do not work, only the Previewxxx events get called. Still not sure why. I tried PreviewGotFocus. The text gets focused, then when I lift the mouse, the focus is lost. I don't handle any other events on these controls. So I handle PreviewMouseUp. This seems to work, but there appears to be a bug in WPF. If I call SelectAll() on the control, it toggles, if I click on a control, then click on another, then click back, it DESELECTS all. So, I tried adding code to clear the selection first, makes no difference. Then I added code to manually set the selection. This works, BUT, now when I have selected the text, the app will take no more mouse input until I focus on another window, then focus back. I added code to set the focus to the control, this makes no difference. This mess is what I have now, and it still does not work. private void ProcessMouseUp(object sender, MouseButtonEventArgs e) { TextBox tb = sender as TextBox; if (tb != null) { tb.Select(0, 0); tb.SelectAll(); tb.SelectedText = tb.Text; tb.Focus(); } } I googled it and found a class that does what I want. Yes, you have to write your own control to do this. I wasn't asking for help anyhow, my question remains, why is this so complicated ? Why is it so buggy ?
Christian Graus Driven to the arms of OSX by Vista. Read my blog to find out how I've worked around bugs in Microsoft tools and frameworks.
modified on Monday, September 20, 2010 7:51 PM
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
-
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?
agolddog wrote:
The people I work with are just in love with forms applications
My bet... They will have to learn how to do web app used as win app... Plus don't forget the cost of rewriting everything... It's easier to choose the technology on new project but there is often no cost effective returns on rewriting (unless your existing app needs to address new goals)... There is no web vs winapp: There is a need and a goal to serve...Choose the technology that will answer it... Cheers!
"Nothing is lost, Nothing is created, Everything is transformed" Lavoisier http://wlwilliamsiv.com