The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
It is a constant source of frowning for me. After decades of activity in UI software development that the tools to design, create and maintain them are still so so so hard to use, fragile and seemingly ill-fitting to the problem domain.
One would think after so much research, use and development it would be a solved problem by now.
One of the funniest and representative moments for me was when I started doing C# work. I had been working in the Java desktop space for a few years and was very familiar with it, particularly layout managers. Come Java 1.5 and 1.6 they had released a set of new layout managers and modified the core part of swing to support them (aligning to text baselines, so obvious in hindsight). They were fantastic. They solved layout issues so easily and superseded all the grid layouts and previous hacks people used to work around things. I love you GroupLayout.
Then I moved to C#, and imagine the surprise when the layout mechanisms were the same as Java's, but from 4 years prior. Grid layout, flow layout and docking along edges. Sigh. Insert sad smiley here.
On a related topic, I miss Java 1.5 synchronization mechanisms. They made things so much easier. java.util.concurrent - I miss you.
Future<t> : A nice representation of the concept "Something that produces a T, but we're not sure when it'll be ready"
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.
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.
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.
As you know, I don't do much WPF these days except for demo apps and pet projects - but I find it far more appealing than WinForms. I do run into dead-ends once in a while and it takes me longer to figure out compared to WinForms, but it's still fun (specially since I don't have a deadline or a boss who's waiting for an update for these home projects)
Yeah, I agree, the end result is so plain cool that I'd never use winforms anymore. The issue is, why are there so many bugs that surely someone would have noticed, if any testing was done. Remember the mouse focus bug you found ? That sort of stuff just comes up far too often.
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.
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.
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:
new RoutedEventHandler((sender, args) =>
(sender as TextBox).SelectAll();
The opinions expressed in this post are not necessarily those of the author, especially if you find them impolite, inaccurate or inflammatory.
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.
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.
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
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?).
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?
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.
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,
"Lasting peace & happiness for ALL human beings!"
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.