Why wpf is not ready for lob

If you use the default ValidationStep which preserves pre SP1 behavior , then you will have a combinatorial explosion in the number of value converter objects you must write.

Furthermore, it limits your ability to dynamically load value converters and therefore replace existing value converters depending on context. Unfortunately, ConverterParameter still cannot be dynamically bound to, and therefore there is still yet another source of code that can result in combinatorial explosion of classes being written to accomplish trivial tasks. There is yet another scenario you might not have thought of that is much harder than it should be: Navigation.

In particular, hard state versus soft state. Currently, WPF determines for you what it considers hard state and what it considers soft state. To some extent, this is a good thing, since it roughly approximates how the Web works. In WPF, this hard-vs. However, doing so is a challenge because NavigationWindow does not expose its internals; the design of the entire navigation mechanism at release was pretty bad, all the way down to the ugly default browser bar that makes me hurl just looking at it.

This would allow me to pick what kind of navigation I want to provide the user. For instance, fisheye, etc. But it is really difficult to have a clear answer even from MS. I think there is a marketing point of view and a technical point of view which may not be the same. And even the next release would not be better MS source. Of course, i use conditionnal and we are investigating further on this subject ….

My personal experience with performance is quite positive — I have re-developed a booking system that was originally developed in VB6. It is difficult to compare speeds between the old app and the new one because the new one is far richer graphically and this richness takes rendering and that takes time. However I have managed to reduce rendering time down now so that the new app takes only ms longer to render than the old one, this is rendering a scrollable grid with sometimes two thousand rendered objects populating the grid.

I, for one am quite excited about WPF. I am hoping that a new age of application design is ushered in where finally looks and functionality are back on the priority list! I have to say that my client is quite progressive in how they think about technology which made selling WPF as the technology to use easier.

In coming from a mixed web and client background, I find the technology liberating from the shackles of making applications that look like Windows 3.

It definitely opens a door to allow you to start thinking of new ways to visualize data and present it to users in ways that engage and encourage them. After all, thats what LOB apps should be for. As a platform, it is complete. This is the reason most LOB applications are developed using windows forms. It is ridiculous to say that this is not a problem. This is also ludicrous to say - this is simple to write enterprise level applications - considering that tons of books were written about it.

It looks strange for me to hear that the same "smart people" bump to some issues utilizing WPF from project to project I hope that was at least not the same issue. I don't want to say that WPF is ideal. Surely in my practice we had bumped into some WPF "surprises" but they all were avoided and managed I'm also talking about a set of mid and large size projects. I can just confirm that WPF is not simple to start with it so the good development will not be at a low price.

When you are running any WPF application, the Windows timer resolution is bumped up from And this happens even if you aren't doing anything that needs that resolution.

This wastes both CPU cycles and battery life. These kinds of design problems are all over WPF. Some are internal and potentially fixable, others are a result of offering too many options to the application developer.

I got a bad feeling since I first saw WPF. The whole model did not seemed justified, when you are making an installed application. Can there be something more fundamental at play here? I think the problem is ownership, it seems like it is the lesser evil that a platform is owned by everybody. That if it is owned by a corporation. The reason being is that in order to make money a company has to limit access. And those "artificial" limitations eventually hurt the technology adoption.

Nobody controls the browser world, microsoft tried to control it and failed. With all it's huge problems it is dependable, in that it will be there for good. There is a spectrum of solutions and opinions here, but it's clear that web tech is evolving aggressively to close the gap with native applications platforms: developer experience, deployment, management, etc.

In my opinion, this is clearly the future. Like Print Bookmarks. Jul 04, 8 min read by Jonathan Allen. Related Sponsor Stuck trying to diagnose connectivity or performance issues? Author Contacted. This content is in the Architecture topic. Anomaly Detection Using ML. Records in C 9. The Fundamentals of Testing with Persistence Layers. Measuring Value Realization through Testing in Production.

Building a Source Generator for C. Private vs. Public Blockchains for Enterprise Business Solutions. Hibernate Releases Version 1. GraalVM Are Canary Releases an Alternative to Testers? View an example Enter your e-mail address. Select your country Select a country I consent to InfoQ. Hello stranger! Get the most out of the InfoQ experience. Tell us what you think. Email me replies to any of my messages in this thread.

Community comments. Watch thread. If Build Conf. Like Reply. Back to top. Great write up by harvey siege ,. P Windows Desktop by Alfredo Canas ,. Re: R. P Windows Desktop by Jonathan Allen ,. Re: If Build Conf. No Surprise Here by Andy Till ,. Look around P Windows Desktop by Andreas Kleffel ,. Great summarization of problems! I've started a LOB application and the original plan was to go for Silverlight And besides Xaml is no speed demon.

If I didn't wan't it to look pretty than what is the point of using WPF. Only I'm not a Designer so mine is going to look like banta fudu. I don't want to use two programs to write software. And if you think that Cider is working well than you clearly haven't used it much.

The interface sucks. RAD environment?????? Are you kidding? Is that crack pipe good? You should tell jokes for a living. I'm disconnected? I used this stuff everyday, unlike most of the WPF cheerleaders who make a living selling books about new things and people like you that won't say anything negative about Microsoft even when it sucks.

Listview is more than enough for most applications! Are you kidding! Your one of those people who answer the phone with a technical problem and they say, "why would you want to do that". How could you possibly know that Listview could meets the needs of most people!

You know I shouldn't have said that xaml was hard. I should have said it was completely un-neccesary. It complete goes against a wysiwig environment. I must admit I've got a little irritated about WPF. The reason I care is because people like you follow Microsoft like lemmings.

You would happily walk over the cliff and kill yourself on the rocks below never questioning whether it was best decision and because of that WPF will be adopted and since I've made my living writing software since the early eighties, I've seen languages come and go, but are we any better off?

I really hate adopting something that is pointless, but if everyone else does that leave's me alone with no support, no help, no cards, no interfaces, no drivers.

At some point you have to go on, even if it isn't really a step forward. I was offering my opinion and your condesending remarks where un-neccessary. Come on. If you had to re-write 3 very large programs.

Would you re-write them in Winforms? It wouldn't be the smartest thing to do. I may be forced into using WPF but I don't have to like it.

And I didn't start the insulting. I just reponded to an one. And I thought we were. The original poster asked for an opion, I gave mine. Just because you didn't like it does not make it wrong! I don't know how old you are but really, stow your comment away for a few years. Say, 10 or so. Come back to it and re-read it. I think you might have a completely different view.

Once your software has been trashed a few times. God forbid anyone give an honest opinion. Forgive me for messing up your happy thread.

You guys continue blowing smoke. Forget I was ever here I don't think people are blowing smoke. Basically in regards to capabilities of the framework, it would be naive to suggest that Winforms is more powerful than WPF. I understand where you are coming from, I think we all do in here.

Right now WPF is still very much in the early adopter phase. For us, it's almost like having cold water thrown on us when we give a speech at the local. We have used the platform and tackled the learning curve head on and are at the point where we definitely see the raw power that WPF brings to the desktop. Unfortunately, a few veiled jabs have been thrown back and forth, but trust me when I say that we are not trying to look down at you.

Believe me, I understand, sometimes you're doing as much as you can to stay afloat and management doesn't see the benefit in allowing you to research and expand your skills. In the long run both you as a knowledge worker and the company suffer because of their lack in foresight. Yes learning WPF is a daunting task. But it is also rewarding.

Taking the challenge on strengthens not only your skills with WPF, but it also makes you look at other frameworks with a different mindset. I don't think there's anyone here who doesn't understand that WPF is not the choice for everyone right now. However, given the opportunity, taking the winforms track over WPF would definitely be a career-limiting decision. Quite the contrary. I make a living writing user interface control software for both windows forms and wpf, and I'm in a very good position to assess the market for both.

I'd still prefer to write a new application in winforms for some areas because WPF needs to become faster or hardward to catch up and I'd prefer to write in WPF for other areas. I do agree that if you're coming from a winforms world, XAML should be unnecessary. We've come from a world when we dragged and dropped to create interfaces and never had to touch any of the serialized code that resulted, to a world where suddenly we're expected to care about this code, and care bigtime.

At first glance, that appears to be a step backwards - and it is, in many ways. The fact that XAML is pretty powerful mitigates it somewhat, but not entirely. Not until we can configure all the databinding goodness of WPF in the visual designer anyway. There certainly are plenty of cheerleaders around here but that doesn't make them wrong. These threads are great because we all have different points to make and they're all correct.

We are now in our second year here and the response to our group has been fantastic. Unlike most. Net Groups, including our local developer one. Something I don't really understand about the developer community is their lack of wanting to use WinForms Integration on WPF or for putting WPF inside winforms which you can do as long as you watch the Z-Ordering and know the limits. Why it was cancelled I never got the full story, but it's worth looking at, as proof that it's really possible to do this effectively.

Sure there are some other issues with it, but as proof it's quite up there. There was also a financial applications in WPF contest that won quite a few accolades.

My view on this whole thing is the Visual Studio Developer community and I hear this a lot is still spooked with WPF, because of the sophistication of XAML and the fact that Microsoft left some very ubiquitous controls out of there, so UI building required a bit of knowlege about graphics though graphics designers probably would not consider it a lot instead of dragging a control and just setting properties.

I hear a lot of developers say "well I don't know about this user experience thing" and I want to code and not be a graphics designer. If I had all the winforms controls it would be great, they have default styling and I can do UI stuff as a no brainer.. That's all well and good, but when your application starts competing with applications from other platforms, the Windows one sort of looks so 10 years ago and people cringe when they have to use a Winforms application because it's not asthetically pleasing.

Developers are also resistant still and don't understand the work flow of letting a designer help them. They worry about version control, and a whole bunch of other things which are more paranoia than fact.

WPF and Silverlight take us new places and it will take a while. Someone saying it's not ready isn't really saying the technology isn't really ready it is, and SP1 of WPF will even shine brighter , however you need to talk to a designer.

Not everything in WPF has to be animated or do a special effect that doesn't run well on old hardware.. This is not the time to stay in "the box" with your thinking and look outwardly. You won't find these people at. There's a reason for that, most designers won't touch these people because of their pay practices, and beyond things like event handlers most UI folks don't code anything but UI..

So you have to figure out where these folks are if you want to hire them, we know and can help you.. Most of the comments by folks here don't represent the actual situation in the market, but people needing other folks that are around and available and they are seriously in DEMAND.. All in all people don't want to have to learn new they don't like change too especially programmers.

Thank you for your comments. It's refreshing to hear someone that understands the problems of taking older applications into a new platform. It really isn't all hearts and flowers, and if we as developers don't let others understand the problems they will face the platform will not get better. My tone has been yes, been negative. But sometimes seem to be the only way to bring out the things needing to be discussed.

Eitherway, we are planning to buy Infragistics Netadvantage controls for Winforms or WPF, depending on where we endup. I am going to keep this post open till we make a decision and post it here, so all the contributors know where we ended and why we ended there.

Later it was VB6 and now slowly getting into WinForms. I agree. It's not faster. It's not easier to use. It just look nice. I can run almost all the samples that I downloaded on XP and Vista without much difference.

I am recommending the use due to the richness in databinding, separating the designer from developer, etc. You have to invest time in understanding the difference. Have been discussing the very same thing with MS people but obviously haven't got to the answer that you have just yet.

Still struggling. Can you elaborate on any specifics, especially on the "not stable" part. The MS person said, it is not ready for the primetime because of the maturity, toolset gap and not stable. Unfortunately I did not attend that meeting, I had another conflict.

The people attended the meeting were for WinForms, so they did not probe more on the specifics I guess. If you hear anymore about the specifics I would like to know before I hit the same problem.

It really could help make alot of our minds up about things. I would meet some of the MS guys on Friday 23rd. Will post the details as soon as I get em. This is the exact reply from MS people Net as a top priority. A bit further down the road, customer would look at WPF more aggressively. So he basically got the answer he wanted In the beginning I too was disappointed because I was so used to developing graphically using drag and drop facilities.

When Microsoft sent me the early beta versions of the. All of the applications I've developed are LOBs, so I suddenly found myself asking if I had to learn to become a graphic designer in order to respond to my clients' needs. Most of the books about WPF at the time were about how to draw snazzy buttons that spin. I realized that building a LOB app would take longer. But we need to realize that WPF is still in its infancy. Microsoft is making sure that the framework is ironed out before it adds the bells and whistles in Visual Studio.

Recently I looked at Visual Studio. It's only a matter of time that the WPF tools will be everything we ever wanted it to be. For those of you who don't like XAML, you have nothing to worry about.

Most of us are upset now because we have to resort to 3rd-party tools to get the controls we need. As a LOB developer I know that this could be a problem because not all clients use the same third-party tools, so we're stuck having to learn a lot of 3rd-party tools.

From what I see, this debate is simply the usual debate we all go through when a new technology comes along. Yes, I did run into some specific problems with WPF and some were solved with work-arounds, but I remember years ago I had to do work-arounds in VB6 as well.

That's so 90's! No really, it's totally useless. How long did I spend trying to get my controls to dock in the right places or nest correctly? Indeed you don't need to edit xml. There is a visual editor, which is not Blend. But after some months of use, you discover that it is very efficient. Docking in the correct way is easily solved by editing the xml. Well, no, it's no easier than learning, say, IDL. I have a strong feeling I shouldn't need to know it.

I don't think it is harder than learning winforms classes, properties, events, etc. But wait! So, how it is more difficult? If I have low confidence, I'm less likely to recommend its use, because here in the real world we get paid to get things done.

Own experience is not needed in advance since there are lots of benchmarkings about WPF in internet. A well done benchmark should increase your confidence.

Not really. It depends on your situation. Personally, though. I am getting a little sick and tired of being forced to consider recoding and migration every time Microsoft wants to hang its hat on a new technology, just so I can keep up with its "recommended styles," "best practices," and "intended direction".

I suggest that you only use ElementHosts in a limited number in an app or as a temporary solution when converting a larger application.

An example of a bug is if you host an ElementHost inside a WinForms scrollbar then you in many cases have to disable hardware acceleration in WPF due to your WPF being drawn incorrectly. An example of concerns is some events e. When someone presses h or any other key in WPF it is not the same as in Forms thus you cannot just let this key press pass through the ElementHost you have to actively handle it.

I have used ElementHosts for a few years and there are often situations where something does not work which you would just expect to work out of the box in a pure Form or WPF app. If you mean multimedia, animation and future proofing your code, than WPF is probably better. Be advised that you are going to pay for the extra features that come with WPF through more CPU activity and memory usage. Right now, I don't think Microsoft has an obvious technology for Windows apps.

Windows Forms is dead and has been for years. WPF was supposed to be its successor technology, but it never really caught on to any great degree.

Last year, Microsoft admitted that WPF's sister technology, Silverlight, has lost the war for the Web, and was being repurposed for Windows Phone 7 development. It would be nice if Microsoft could tell us what technologies they'll be recommending for the future, but it doesn't look like we'll know anything more until the BUILD conference in September. I think the definition of LOB is changing as well as the techonologies.

Big buisness are now also based on new interfaces. Everyone wants their applications to look nice. Probably the only LOB apps that dont have a good interface are the apps for some institutions like banks. But they are little part of the whole LOB. As i talked with a firend architekt normal architekt the programmers are quite lucky because we have alot of work to do. It is not like we make a building and than noone needs the architekt who develop it, here you always need a strong support of programmers and admins.

Especially if you have some extra money to invest in some nice controls you can make really miracles. We should always try new things and explore them. I cant understand people who know only windows forms and they dont want to make something new.

This is exacly the magic of beeing a developer you are not forced to repeat every task the same way, you can always imagine and make your life little bit easier sometimes harder :P.

Depends how you define a LOB application…if you are replacing simple VB like apps that focus on queries, Lightswitch seems to be a step towards the right direction.

If you want something more complex, with custom behaviour etc, the only way at the moment is to do it in WindowsForms. You may as well use HTML and javascript if you like being in that situation. The point that MS seems to be missing is that if I need a powerful UI development platform on the top of my LOB solution, it has to be simple and not require 10 years of study before I learn how to do the same thing in different ways for no reason.

Anyway, that is history now, since we are supposed to be hearing the new direction in UI development in September or something. As long as XAML remains as convoluted as it is and WPF with its retained mode of operation makes the simplest tasks require 25 scripting behaviours, I would advise everybody to stick with WinForms and deliver on their projects.

LightSwitch does all the things you mention. You don't need a designer, just buy a new Shell and Theme. It is not just for simple stuff. I still need to find the time to evaluate Lightswitch properly, but I do not doubt your statements about it. I personally think that they have done a good job all these years with VB and associated technologies to support businesses that need quick solutions. Now they seem to be going back to their roots with applications like Lightswitch that seem to provide real solutions to real problems.

Offering products that leverage these technologies to make life simpler Lightswitch-Silverlight is a step towards the right direction. I agree that LightSwitch is the answer. We just needed to give MS the time to iron out the underlying technologies in order to have a product like LightSwitch come out and improve our productivity.

Because I knew one day, Microsoft would come out with a product that would automate or simplify the plumbing. If you were a programmer back in the late 80's or 90's like me , you would see a similarity here.

You no longer need to master the underlying technologies, although it would be an added plus if you knew it, but it will be hidden eventually in future development products. LightSwitch is a hint at where we're heading, especially for shops that want to save money, which pretty much includes everyone.

These apps are a fairly complex combination of large amounts of simulation data many ComboxBoxes, ListBoxes, etc Nothing really seems "better" about WPF but I did run into several drawbacks:. The exact same data and controls had no issues whatsoever in WinForms and worked perfectly out of the box.

Seems like a huge oversight and you would think WinForms control features would be the baseline for WPF? Many of the threads I read about this suggest "just embed WinForms controls". Ok sure, but they don't even show up in designer mode and if WPF is so good, why am I even considering embedding a WinForms control?

Anyway, that's my 2 cents. I guess maybe they look a bit nicer though? How did you get graphics to work in a time which was anywhere near reasonable? It's a while since I did WPF or any desktop development but when I tried to create a simple cellular automaton application the whole workings of the canvas I think it was sent the whole thing into a crawl. After searching and not finding a decent answer, I pretty much left WPF behind and switched back to WinForms for a while.

Net 4. You are now able to control how crisp your text should look The amount of work involved in order to do this should be very limited opposed to implementing some new features. It should however be noted that you can find almost anything you need in a quick search. Especially the WPF extended toolkit is usefull. They never made the controls available because they stopped investment on WPF and focused on Silverlight…then they minimized the investment on Silverlight and focused on HTML5.

I still do some personal development on WPF, just because I need to write something quickly to test my framework. I am using very basic styles and behaviours and it behaves reasonably still very annoying though. If I was to write any graphically demanding app or something I want to sell at this point it would be done on MFC and Direct2D, then again that is my programming background.

Does anybody recall the Direct3D retained mode of operation…did it get removed after DirectX version 6? Retained mode of operation is so annoying and counter-productive. I would like to see what is the new direction MS will choose, as far as UI development is concerned.

For me though I would like something more "low level" that lets me be in control and program the UI in C Yeh, no code behind but unnecessary XML tags later and you still cannot produce any sensible results behaviour or performance wise if you don't follow the examples to the letter.

Thanks for the info, Lightswitch seems more extensible that I would imagine and also gives a nice structure to the project. I think I am going to invest some of my holidays coming soon , to evaluate this product. Remove From My Forums. Archived Forums. The community is divided, just like the experts are. Some things WPF is right for, some things it's not yet right for. The best thing you can do is analyse whether it's right for your specific project. If there was one answer, you'd already have it.

Hi, Microsoft is well aware of the need for LOB controls for WPF applications, and though I am not allowed to name a date, I can tell you that we will have some very soon. WinForms is obsolete, and don't forget that WPF is a technology progressing VERY fast, so information given even a couple of months ago is to be taken with care today. The message is changing. I would definitely recommend at least considering WPF seriously for any new Windows desktop development.

Greetings, Laurent. The WPF architecture has some problems and early adopters can expect to hit a bump or two as they iron out these issues, but here's a basic fact about software development: When using object oriented coding, the shape of your application evolves from the shape of your base classes.

Above all, be wary of anyone telling you windows forms is obsolete. It's not. Hi Tim, I very respectfully disagree. Maybe it's not totally obsolete now, because of the big number of WinForms designers out there, but with the same thinking we could say that VB6 is not obsolete. Just curious, did you attend the summit? If so, did you get any message about WinForms?

There is a future for WinForms developers because of the number of applications that must be maintained. For any new development today, WF should be seriously considered as a replacement, or as an extension, of WInForms development. For people working in big projects, who need to think 2 to 5 years in advance when we choose new technologies, WinForms is not suitable any more.

Looking forward to hear counter arguments in the sake of a stimulating discussion Laurent. There are a lot of great points raised on this thread. Now my two cents Some people use VB6. In ten years from now some people will still be using WinForms. For any number of reasons. With the help of 3rd party controls to fill the gaps, there really isn't too much missing.

As time goes on, and Microsoft devotes an increasing amount of resources to WPF improvements, the story will only get better and better. But, does WPF make sense in your corporate culture?

Well, that's a different and much more difficult question. Hi Josh, I couldn't agree more what a surprise, huh? VB6 and WinForms are still in use, will remain in use for years to come, but that doesn't make them non-obsolete VB6 more so than WinForms, granted Actually, I was really surprised last year to hear Microsoft tell me that MFC is getting renewed attention in Redmond, and that they even recommend considering it in some cases.

Of course it makes sense when you think of it, since MFC has capabilities that WPF will likely not have before a long time. However, I never got this message for WinForms anymore, which is why I respectfully advise against it. That said, my company still has a lot of WinForms development going on for existing products, and it's fine by me. Have a great day, Laurent. Laurent, Yes, I was in those sessions. Asking which is best on a WPF forum was a bad idea in the first place Tim. I agree with both of you.

Tim is dead-on accurate about the fact that right here and now WinForms is certainly alive and kicking. I think the important point here is what you are building and how far into the development you are already. For those of us firmly entrenched in WF already, it is certainly not obsolete yet.

For those of us looking to the future, it does not make much sense to cling onto WF when WPF is the new rising star. I had started to write a reply to Tim sorry that we didn't meet in Seattle, BTW , but Josh says pretty much what I wanted, just that he says it much better. I should have mentioned that I work in a firm where the typical project lasts 3 years, and in these conditions starting a new project with WinForms doesn't seem like the best idea.