Coffeehouse Thread

138 posts

Do you find WPF to be unnatural / unlogical?

Back to Forum: Coffeehouse
  • User profile image
    W3bbo

    So you're telling me that you prefer WinForms "multithreading"?! That is, accesing a control from a different thread is not allowed in theory but in practice it works or not depending on the control type, windows version and the phase of the moon.

    No, I call BeginInvoke or Invoke every time. It works well for me, my only nuance is why Microsoft never included a "delete void Void();" in the original .NET Framework and why I have to define it in every project I call BeginInvoke in.

  • User profile image
    Sven Groot

    Microsoft never included a "delete void Void();" in the original .NET Framework 

    Ahem!

    It's been there since .Net 1.0. And it's specifically meant for use with (Begin)Invoke.

  • User profile image
    W3bbo

    , Sven Groot wrote

    *snip*

    Ahem!

    It's been there since .Net 1.0. And it's specifically meant for use with (Begin)Invoke.

    To be fair there is no mention of MethodInvoker anywhere on the BeginInvoke documentation (only Control.Invoke, and it's buried in the Remarks section).

  • User profile image
    Dexter

    No, I call BeginInvoke or Invoke every time

    OK. But WPF works pretty much the same. What's the downside then?

  • User profile image
    DeathBy​VisualStudio

    @Dexter:

    What you quoted from W3bbo is the downside. Apps riddled with thread management aren't pretty much the same.

    If we all believed in unicorns and fairies the world would be a better place.
    Last modified
  • User profile image
    spivonious

    Just to put in my two cents, I agree that the designers in 2008 and 2010 are worthless. I always write straight XAML so I know I'm getting exactly what I need. The designer is just there to double-check that my XAML is correct.

    Multi-threaded apps need thread management. I'm not sure what the big problem is there. I can't find the link, but I think it was Bea Stolnitz who had a nice simple implementation of a thread-safe ObservableCollection. It is surprising that this class isn't built into the framework.

    I haven't seen any apps that were obviously WPF in the wild, but any new internal app I write is likely to be WPF. The fantastic support for databinding makes crafting a UI child's play and infinitely modular.

  • User profile image
    Dexter

    , DeathBy​VisualStudio wrote

    @Dexter:

    What you quoted from W3bbo is the downside. Apps riddled with thread management aren't pretty much the same.

    Indeed, but this has nothing to do with WPF. Other UI frameworks have the same problem and in general we're still far from making multithreading easy, safe etc.

  • User profile image
    vesuvius

    The truth of the matter is that it takes a long time to get an application framework right. It was like that with Winforms, and that contained a few new controls, but a lot of the functionaity was a wrapper around the Win32 API (tell you some thing you did not know already)

    WPF will probably reach a satisfactory level of stability and usability in the next couple of versions. after that we will move onto the next big thing. I am currently working with DevExpress controls - not through choice mind - and boy are we coming across some bugs. Each time we update the controls, a few days are lost in the development tracing down bugs, so it really is prefable to tackle projects with something like Winforms, where most of the issues are sorted out, and all the bugs are known with workarounds or avoids.

    I think a lot of people need to step out into the real world, away from hobby projects and into the world of producing software for companies and you will find uptake of WPF pretty high.

    I am constantly turning work down, because recruitment agencies cannot find enough people with modern .NET 4.0 skills so there is a marked difference between the hypothetical bashing and FUD in this thread, and the real world. I don't hope to convince or see any placation of this fact, but WPF is gaining traction, and a lot of applications are creating experiences that would be otherwise impossible.

    I cannot point you to any examples because of the nature of the clients but trust me WPF is kicking backsides, and in the next few years something ubiquitous will arrive, it's just that in the world we live in all the essential tools like downloaders, browsers etc were already written, so visibility for the Bass type people will be non-existant hence the supposition of low uptake.

  • User profile image
    DeathBy​VisualStudio

    , vesuvius wrote

    I think a lot of people need to step out into the real world, away from hobby projects and into the world of producing software for companies and you will find uptake of WPF pretty high.

    I am constantly turning work down, because recruitment agencies cannot find enough people with modern .NET 4.0 skills so there is a marked difference between the hypothetical bashing and FUD in this thread, and the real world. I don't hope to convince or see any placation of this fact, but WPF is gaining traction, and a lot of applications are creating experiences that would be otherwise impossible.

    You nailed it vesuvius. Those of us working on real world applications that have issues with WPF must just be incompetent. Those incompetancies are voiced in FUD. Our every day issues with WPF are all just hypothetical. Thanks.

    When we first started with our WPF application (production business app) we brought on some big guns like yourself -- and yes they were in high demand. When talking to them about their other projects you come to find out rather quickly that very few of them make it to production or are scaled way down in order to save face and get something out for all the money spent. After the first couple of sprints to nowhere they chuckled and said "get used to it -- you'll build & tear down several times before you get it right."

     

  • User profile image
    W3bbo

    The truth of the matter is that it takes a long time to get an application framework right. It was like that with Winforms, and that contained a few new controls, but a lot of the functionaity was a wrapper around the Win32 API (tell you some thing you did not know already)

    WPF will probably reach a satisfactory level of stability and usability in the next couple of versions. after that we will move onto the next big thing. I am currently working with DevExpress controls - not through choice mind - and boy are we coming across some bugs. Each time we update the controls, a few days are lost in the development tracing down bugs, so it really is prefable to tackle projects with something like Winforms, where most of the issues are sorted out, and all the bugs are known with workarounds or avoids.

    Basically your argument is that WinForms is better for development right now because it's more mature than WPF. That's a fine argument to make...

    ...except that WPF has been out since mid-2006, making it over 4 years old now.

    WinForms didn't change much in the .NET Framework 2.0 (which, co-incidentally, came out 4 years after 1.0) but was still arguably a very solid UI framework even when it was new. Most of the improvements have been with the designer and the addition of new controls.

    So I really don't buy that argument.

  • User profile image
    vesuvius

    I am saying that for a lot of applications Winforms makes alot more sense, and like-wise WPF makes sense for alot of other applications. I have worked on several lsarge scale WPF applications in recent years, and all of them have been hybrid applications where a control worked best in some situations that was made in Winforms.

    In agree in your assesment in the slowness of WPF starting up, but the ability for developers to change an application using data templates and the flexible layout system, has resulted in applications that are pretty much impossible to do in Winforms. It is quite surprising what a developer can come up with in an iteration with some SCRUM pressure, where they would have been left scratching thier heads in winforms owner drawing conrols.

    I am currently working on a hybrid WPF application, and the WPF part always takes at least half as long to do as the winforms part. It is a high performance scientific instrument with a lot of precison and math and WPF has really shone. My only regret is the lack of mature open or commercial source controls (graphs at the moment that can render 1000's of points without lag), otherwise we would have gone for a complete WPF application.

    I also have a few graduates that are finding it far easier to grasp and use Winforms as opposed to WPF as conceptually the hurdles are just too high for them at present. It will take time for people to come round fully to the merits of WPF, but they will, and peoples issues will be dealt with though I find it hard to see a reason to update our current application to Visual Studio version next as we have a pretty complete toolkit. Time will be taken to optimise things, but I have not had the horror stories with speed on the whole because you can always reduce load up speed with some smart coding

  • User profile image
    brian.​shapiro

    @W3bbo: I don't know what other people's prerogatives are here, but as someone who knows both WPF and WinForms, I prefer using WPF both because, also a designer, I can create better looking and functioning apps, and because I like the platform. In cases where I have to make workarounds against some of the limits of WPF I just do that once and reuse the code. Of course that's just my decision.

  • User profile image
    magicalclick

    @spivonious:

    I know DataBinding for me is awsome. I have actually implemented databinding on htmlDOM using jQuery. DataBinding is amazing because changing the visual is so easy. The template is very modular and I can change it with little efforts and the potential of me screwing up is low as well.

    It is certainly vast though. I typically don't do dictionary (translation, forgot the term) on the binding. And the dynamic update is not that great. I have to use background worker or pinvoke, messy and typically freez an application, (Mine is crazy 40,000+ photos, so, it is my fault). Although, WL Photo Gallery can handle my photos collection effectively, not sure how it works (Wave 4 only, wave 3 crashed).

    Suggestion:

    I think it would be great if MS make some kind of framework on top of WPF to do dynamic update gracefully. Like, some kind of buffer loading the update in an external thread, and once it is done, switch the current thread to the new result. The background worker is heavy because it has to halt the GUI and making the update.

    Another thing I hope to have is the managed photo element. LIke, when it is hidden/collapsed, it use single color. When it is visible, it will load specified tiny preview, like 10x10. And when it is actually visible in the scrolling view, it will load decodewidth at element width. I tried to do it myself, but, the checking "actually visible in the scrolling view" is rather hard when I have 40k photos.

    Leaving WM on 5/2018 if no apps, no dedicated billboards where I drive, no Store name.
    Last modified
  • User profile image
    Bass

    , vesuvius wrote

    The truth of the matter is that it takes a long time to get an application framework right. It was like that with Winforms, and that contained a few new controls, but a lot of the functionaity was a wrapper around the Win32 API (tell you some thing you did not know already)

    WPF will probably reach a satisfactory level of stability and usability in the next couple of versions. after that we will move onto the next big thing. I am currently working with DevExpress controls - not through choice mind - and boy are we coming across some bugs. Each time we update the controls, a few days are lost in the development tracing down bugs, so it really is prefable to tackle projects with something like Winforms, where most of the issues are sorted out, and all the bugs are known with workarounds or avoids.

    I think a lot of people need to step out into the real world, away from hobby projects and into the world of producing software for companies and you will find uptake of WPF pretty high.

    I am constantly turning work down, because recruitment agencies cannot find enough people with modern .NET 4.0 skills so there is a marked difference between the hypothetical bashing and FUD in this thread, and the real world. I don't hope to convince or see any placation of this fact, but WPF is gaining traction, and a lot of applications are creating experiences that would be otherwise impossible.

    I cannot point you to any examples because of the nature of the clients but trust me WPF is kicking backsides, and in the next few years something ubiquitous will arrive, it's just that in the world we live in all the essential tools like downloaders, browsers etc were already written, so visibility for the Bass type people will be non-existant hence the supposition of low uptake.

     

    So you are saying that WPF is very popular internally? I suppose that could be true, but in the realm of shrink wrapped software we are seeing nothing.

    Than again I don't see much Winforms stuff out there either, certainly it's more than WPF but you have to consider how many web apps are there vs how many fat clients. A lot of stuff has moved to the web. Even traditional fat client stuff like tax software seems to be moving more to the web. I don't see many fat clients that aren't video games or anti-virus in the stores over here in the US anymore either.

    Going back to internal software (also what I write)..

    I work for a very, very large organization and we have this massive internal wiki with all kinds of info. If you go look for .NET, there is an article on it. But it calls it a "scripting language" and the last time the page was updated was 2007ish.

    Literarly nobody uses .NET where I work, and we are talking possibly one of the largest software engineering nexuses in the world. Does that mean .NET is not being used? Hell no my previous job was all .NET basically. .NET is huge, but you wouldn't think so if all you know is Java. Our personal experiences will bias what we think is popular. Because quite frankly, as a .NET developer, you will likely never qualify for anything but .NET development jobs, unless you want to go entry level all over again.

    So you get this idea that some technology is more popular than it actually is because that's all you see. When I first got into this Java development thing, I was suprised to see so many people used Java. I thought Java was dead. This is probably a typical view of someone who only works in Visual Studio and .NET. You go to conferences and all they talk about is .NET, you do .NET at work, when you go on job interviews they all happen to be .NET because that's what you know.

    Now I go to Java conferences regularly and I don't see any .NET anywhere professionally. Everything is Java, it's the alpha and the omega and no other programming languages exist except those hobbyist ones that cool people like Twitter use and happen to run on the JVM, which is the only supported way to run applications on a computer. To me, .NET looks like a dead technology. Outside of Channel9, I hear absolutely nothing about it. Everything is Java now. But that's obviously not true.

    It works in reverse too. You can make six figures knowing the ins and out of some obscure TIBCO products. You'll never be out of work either.. but it's an obscure TIBCO product. Smiley

  • User profile image
    exoteric

    Is there any UI framework that is actually thread-safe? I seem to remember that WPF was originally supposed to be thread-safe but that plan was shelved. The API was also simplified to boost performane but loosing a little generality. I don't quite understand why noone is building thread-safe UI frameworks but with the advent of Async the problem should be less relevant because many tasks can be performed on the UI thread anyway.

  • User profile image
    Dexter

    I don't quite understand why noone is building thread-safe UI frameworks

    Because it's not exactly easy? Smiley

    Imagine what happens if 2 threads update properties on different UI elements and imagine that those properties affect the layout. Should both threads execute the layout pass? Use a big fat lock to serialize the layout? That sucks performance wise. Try to make the various data structures that are used during layout thread safe? That's likely to be way too complicated if not impossible.

     

  • User profile image
    vesuvius

    @Bass:If I wanted to earn significantly less that I do at the moment, I would be a web developer. Highly skilled web devs are valuable, but they are ten-a-penny

    Just my two pence

  • User profile image
    PerfectPhase

    , Bass wrote

    *snip*

    Now I go to Java conferences regularly and I don't see any .NET anywhere professionally. Everything is Java, it's the alpha and the omega and no other programming languages exist except those hobbyist ones that cool people like Twitter use and happen to run on the JVM, which is the only supported way to run applications on a computer. To me, .NET looks like a dead technology. Outside of Channel9, I hear absolutely nothing about it. Everything is Java now. But that's obviously not true.

    I find this quite intresing, jump to 32minutes in: http://www.thoughtworks.com/tech-radar-qtb-uk

    They're talking about the concept of Java end of life, not the java platform, just the language and the rise of other languages like Clojure and Scala that run on the JVM.  

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.