Coffeehouse Thread

138 posts

Do you find WPF to be unnatural / unlogical?

Back to Forum: Coffeehouse
  • User profile image
    vesuvius

    @spivonious: It's not just that software is complex, end users expectations are significantly higher than they were a decade or so ago. Most people have been using computers since their youth, and with the advances in mobile technology, and the prices of computers coming down, end users expect a lot more.

    I have the benefit of working for a few recent greenfield projects, without the restraints and baggage that legacy systems afflict on one. People are clued up nowadays, and you cannot fob them off with the complexity stories of years gone by or "it's good enough". When I am in metting people have MacBooks, iPhones, iPads, Vaios, Acers, Androids, Kindles and so on...

    Winforms is simply not going to impress them, this is not an isolated case.

    I still will take the opportunity in this thread to advise people against using DevExpress WPF controls, because they are guiltier of the academic approach more than Microsoft, and their WPF control suite is terrible. At least with a lot of the native WPF controls I can extend them, and with a few design practices it is enjoyable to write software that amazes end users. Winforms is good for a warehouse requiring an inventory system, but once you move into the scientific domain, you can do far much more with less effort using WPF

  • User profile image
    kettch

    @vesuvius:There are some things that can be more complex in WPF. Binding is stupid simple. Once you start pulling in IDataErrorInfo and ErrorTemplate and make sure your business objects are validating. Then build the whole thing on MVVM and whatever WPF bells and whistles you want. It sounds complicated, and it is. Your net amount of work might be about the same or more than WinForms. However, I feel that you end up with a solution that is cleaner, more elegant, easier to maintain, and easier to extend.

  • User profile image
    AlHudson

    Quite frankly WPF is awesome, is beautiful, is cool, is modern.... and is a pain in the * to learn it... since layout to binding and prism

  • User profile image
    JohnFx

    I'm still relatively new to WPF, but I have to agree with the OP. It seems like it solves all sorts of problems I didn't have, and creates a lot of problems I didn't have before also.

    I'd heard that web developers would find the transition easier, but that isn't the case for me. The problem is that XAML is close enough to XHTML to make you think you might know what to do, but those instincts usually turn out to be incorrect. And that binding syntax is freaking insane. Who designed that crap? This whole thing reminds me of when the SharePoint team decided that SQL (or LINQ) wasn't good enough for their product and they had to create the unholy abomination OCAML because XML was their hammer and everything looked like a nail.

  • User profile image
    AndyC

    , JohnFx wrote

    I'd heard that web developers would find the transition easier, but that isn't the case for me. The problem is that XAML is close enough to XHTML to make you think you might know what to do, but those instincts usually turn out to be incorrect. And that binding syntax is freaking insane.

    FWIW I've never believed the line that it would be easier for web developers. Sure, they're both XML-like syntaxes, but HTML+CSS is probably the most *-backwards way of trying to separate presentation from content ever devised. Anyone used to working with data in that way is going to find the idea of data-binding, despite it being a far cleaner and capable technology, to be a little bit alien.

  • User profile image
    figuerres

    , JohnFx wrote

    I'm still relatively new to WPF, but I have to agree with the OP. It seems like it solves all sorts of problems I didn't have, and creates a lot of problems I didn't have before also.

    I'd heard that web developers would find the transition easier, but that isn't the case for me. The problem is that XAML is close enough to XHTML to make you think you might know what to do, but those instincts usually turn out to be incorrect. And that binding syntax is freaking insane. Who designed that crap? This whole thing reminds me of when the SharePoint team decided that SQL (or LINQ) wasn't good enough for their product and they had to create the unholy abomination OCAML because XML was their hammer and everything looked like a nail.

    have you ever had to mess with windows forms and it's data binding ??

    it's got a ton of issues that can trip you up.

    and win forms layout has a lot of problems *if* you want to make really good forms that do things like flow / adjust to the display size or do any nice effects. not even touching animation etc... just simple stuff that's hard in win forms due to how they put every visual control in a window.

    a large winforms display of one form can have like 50-100 "windows" to make what the user sees are one "window".   at least in wpf  it can be one window!

    no wpf / xaml is not perfect. but what is ?  all of our programming tools / languages etc... are flawed and that's why they keep coming out with new ones trying to get better with each version.

  • User profile image
    spivonious

    After a year or two with WPF, it's very natural and I am more productive in it than I am in WinForms.

  • User profile image
    vesuvius

    It's a case of bad workmen blaming their tools

  • User profile image
    FlatBox

    WPF may be great, but I have following major pain areas leaving aside the the learning curve associated with WPF/XAML):
    - Visual Studio XAML Designer is painfully slow. It is pain to wait for designer to load even a medium size (say 500 lines) XAML once you swtich to Design view. Everytime you change to another file, it seems to be compiling the XAML code that's why it is slow I guess. For that matter, if you are creating a complex GUI, not much you can do with the Designer, every thing has to be coded in XAML. That's not bad, but at least they could have given an option to disable the Designer.

    - Another problem with WPF/XAML is, all data binding has to be specified in string, even for variables which is already defined in the code. For example, I have following code in my XAML code:
    <TextBlock Text="{Binding Path=NumOfItems}"></TextBlock>

    Here NumOfItems is an instance variable in the some class. Make a small mistyping in variable name (NumberOfItems in this case) it will still compile fine, nor it will trigger exception, it won't simply display the value. This small thing otherwise should
    have been caught by the compiler to make life easier. This also makes intellisense useless in such case where we need to specify variable as string?

    Overall, WPF may be a great initiative towards creation of ultimate framework for GUI programming, but it has its own set of problems which needs to be addressed before it will be hugely successful.

  • User profile image
    Maddus Mattus

    @FlatBox: I think the stringbased bindings are a plus, it makes it more loose.

    The designer in VS does the job, if you want a real design tool use Blend.

    I love WPF!

  • User profile image
    vesuvius

    @FlatBox: Are you using a 64 bit version of windows and making sure you are not opening a lot of XAML windows, as I only have speed issues on old 32 bit machines?

    I would recommend you use MVVM, binding to commands and not to properties. Silverlight 5 introduced XAML debugging, which is sure to be included in the net version of WPF. I use Resharper that identifies 90% of my XAML issues so I reiterate "It's a case of bad workmen blaming their tools"

  • User profile image
    spivonious

    @FlatBox: Actually, it does raise an exception, but the debugger reroutes it to the Output window.

  • User profile image
    MasterPi

    Having worked with WPF for a year, I absolutely love it. It feels like if you follow good design, things just sort of fall into place and work as fluidly as you would expect.

    My one concern right now is that it seems that I have to create a value converter for everything when it comes to binding. For example, in one instance, I want to convert a bool to a color. In another, I want to change out the opacity based on bool. I try to reuse my value converters as much as possible (using the converter parameter to make the converter a bit more general). However, it seems I will still need to create a new one for certain scenarios. Is there a better way to manage this? Maybe I'm doing it all wrong.

    Also, including images in the application..right now I have the images in the project directory and I add them in resources. Then, I just refer to them <Image source="component;/Images/[filename]"/> or something like that. Is that the right way to include images WPF?

  • User profile image
    vesuvius

    @MasterPie: I handle all my visibility logic in view models and not converters, which tends to reduce converter bloat

  • User profile image
    vesuvius

    @MasterPie: I handle all my visibility logic in view models and not converters, which tends to reduce converter bloat

  • User profile image
    MasterPi

    Ah, so you just have dependency properties that are of the types you would convert to anyway?

  • User profile image
    mawcc

    @MasterPie: If you're using MVVM you can sometimes avoid Value Converters by creating additional properties in your View Model that do the proper conversion. But I agree that the number of Value Converters tends to grow steadily with the size of the project.

  • User profile image
    MasterPi

    But at that point, it would seem that the View Model isn't exactly independent of the view if you're defining presentation properties specifically for the view.

    Right now, I have a property "UserEngaged:bool" and based on that property, I want to change the background color of my view, hide and show some elements, and change the foreground of some other elements...ValueConverters converting from bool to the right types. Making those into properties would mean coding up specifically for the views and user controls that I am using, which I feel defeats the purpose of the design pattern. 

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.