Coffeehouse Thread

138 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Do you find WPF to be unnatural / unlogical?

Back to Forum: Coffeehouse
  • User profile image
    spivonious

    , MasterPie wrote

    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. 

    I agree. The ViewModel should know nothing about the view. However, if it's something that can be abstracted to UserEngagedColor instead of BackgroundColor, then different views can make different uses of that property. I admit, it's a stretch, but I've come to the conclusion that my apps rarely have more than one view on a viewmodel anyway, so the design beneft of separating the two disappears.

  • User profile image
    mawcc

    @MasterPie: I see the ViewModel as an adapter between the Model and the View, that enables you to keep the Model clean of View-specific stuff. The coupling between View and ViewModel tends to be tight anyway, so I don't mind having some additional properties for the View in there.

  • User profile image
    Dr Herbie

    @mawcc: +1

    I have yet to reuse a ViewModel/Controller with a different view, although I reuse models between different ViewModels/Controllers al the time. I'm happy to have ViewModels/Controllers coupled to Views to a larger extent than other parts of the system.

    Herbie

  • User profile image
    cbae

    , MasterPie wrote

    *snip*

    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.

    *snip*

    It would be nice if XAML even supported a simple InputMask property for the TextBox class. That property has been a part of the TextBox control in VFP since forever. I know Microsoft doesn't want to piss off important third-party control developers like Telerik, but still. 

  • User profile image
    Maddus Mattus

    @mawcc: Mine is loosely coupled via a ViewModelLocator, so you can use Blend with some test data.

  • User profile image
    davewill

    @Maddus Mattus: Which approach did you take?  Something like in the MVVM toolkit or a generic ViewModelLocator like http://johnpapa.net/simple-viewmodel-locator-for-mvvm-the-patients-have-left-the-asylum?

  • User profile image
    Maddus Mattus

    This is what we do;

    <Page.DataContext>
          <MockViewModels:MyFirstViewModel />
    <Page.DataContext>
    
    in the code behind;
    
    [Import]
    public MyFirstViewModel ViewModel
    {
    set { DataContext = value; }
    }

    So when the app is run in Blend, we get no import from MEF and we get a MockViewModel. Saves me the effort of creating a modellocator. In the MockViewModel we do not build data if it's in Design mode.

    You could work with a shared interface between the mock and the actual model, but that just creates more classes. This is the most clean IMO.

    I've used the modellocator pattern in XAML on other projects, but it always tends to add much code, either in XAML or in C#. For simple things I use the solution above.

  • User profile image
    ZippyV

    This week I've learned WPF while making a Metro application using the Win8 dev preview. I watched an excellent MVVM video but for some reason my properties in the code did not get updated when I changed the value in a textbox. Turns out in Win8 Metro databinding is one-way and not two-way like it used to be. Mad

    Now all my databindings need to have:

    {Binding Customer.Name, Mode=TwoWay}

  • User profile image
    Maddus Mattus

    @ZippyV: This is not new, to my knowlegde it has always been OneWay by default.

  • User profile image
    AndyC

    @ZippyV: I think I answered this for you on the Win8 dev forums, but yeah basically it's always been that way. There are some cases that default to two-way in WPF, but they're the exception rather than the rule.

  • User profile image
    ZippyV

    I've only used a simple textbox so far. Here's my Win7 project in VS2010: http://home.scarlet.be/~zippyv/downloads/simpletest.zip

    This shows there is 2 way binding on a textbox without setting the mode explicitly. In a metroified version it doesn't work.

  • User profile image
    AndyC

    Textbox.Text is one of the "two-way by default" WPF exceptions, so I guess they're either standardising on everything being one-way by default (which in many ways is better) or some of the defaults have changed.

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.