Cinch (My MVVM framework) Part 5 is out

I just published part III of my MVVM framework series over at http://www.codeproject.com .

Here is the link

http://www.codeproject.com/KB/WPF/CinchV.aspx

 

This time I talk about

Unit testing using the Cinch framework

 

Enjoy

Advertisements

7 thoughts on “Cinch (My MVVM framework) Part 5 is out

  1. Roberto Dalmonte says:

    Hi Sacha,
    I’m following your article series and I’m going over and over again from article 1 to 5 (and waiting for 6).
    While I’m getting some understanding of your framework (Hey, it’s c#!) I’m somewhat lost in bridging xaml code to cinch. What puzzles me is that in the 5 articles there are only 4 xaml snippets (all of them in article 2). Of those 4 snippets only one can be actually found on the sample app (the one referring the numeric only textbox behavior). None of the views, but the MainWindow, has a reference to the Cinch assembly (What the heck!). Since I’ve being using windows forms for years my eyes automatically and uselessly look for c# in the behind code file.
    Am I asking for a 7th article talking exclusively of the xaml side of things? May God guide your nervous fingers to the keyboard.
    Roberto

  2. sacha says:

    Hey Roberto

    I think what you say is actually fair I have not put so much focus on the demo app yet, that is next up.

    I was not going to explain it too much, but by the sounds of it I need to spend a little bit more time on explaining the demo app.

    So just wait for the next article (part6) and that should have what you need.

  3. […] Cinch (My MVVM framework) Part 5 is out (Sacha Barber) […]

  4. Daniel says:

    Hi Sacha,

    when i debug your demo application and set a break point for example in the customer firstname setter this breakpoint will never reach.

    The value in the firstname field comes to the firstname property but how?

    with kind regards
    daniel

  5. sacha says:

    Daniel

    The demo app uses a new thing I did called DataWrapper, so you will need to put a break point in the DataWrapper class, if you want to debug a setter.

    A few folk have not liked the DataWrapper idea, but I have to say I like it, as it allows the VM to control every fields edit state individually and the UI responds accordingly.

    The downside is that there is some more abstraction as Firstname is no longer a simple String, it is a DataWrapper and the UI binding TextBox to DataWrapper.DataValue for Firstname value, so this is why you never see the setter for Firstname never change, cos its the same DataWrapper as when it started, but the instance of the DataWrappers (used for Firstname) internal DataValue property will see the property changed you see when the Firstname updates.

  6. Daniel says:

    Thanks Sacha for your quick answer.

    I like the DataWrapper idea too and i want to use it, but i need a way to get the changes of my properties. I try to realize something like in-line editing support for the user which results in displaying an valid or error icon on property changed. Do you know an easy way to get this behaviour with the use of DataWrapper?

    with kind regards
    daniel

  7. sacha says:

    The only way I can think to do that, would be for each DataWrapper have another property which takes a callback action (delegate), when a property changes inside the DataWrapper, it could call this callback delegate in parent object, which could raise property changed for the DataWrapper.

    So imagine we had something like

    class someobject
    {
    private DataWrapper<String> firstNameWrapper = new DataWrapper<String>();

    void SomeObject()
    {
    Action action = FirstNamePropertyChanged;
    firstNameWrapper.PropChangedCallback = action;
    }

    private void FirstNamePropertyChanged()
    {
    //raise real property changed for DataWrapper<T> that issues this callback
    }

    DataWrapper<String> firstNameWrapper
    {
    get {…}
    set {…}
    }
    }

    public class DataWrapper

    public Action PropChangedCallback { get; set; }
    private T dataValue;

    public T DataValue
    {
    get { return dataValue; }
    set
    {
    dataValue = value;
    NotifyChanged(“DataValue”);
    PropChangedCallback();

    }

    }

    Do you see what I mean

    This could also be made bullet proof by using WeakReference for callback, so only callback if Source object is not GC’d

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: