In angularjs, the ngModel directive is used for setting up a two way data binding between an input element and the underlying model.By default, the model is updated when the input value changes, for example while the user is typing.

Based on your scenario, having the model updated immediately may or may not be desierable.With version 1.3, angularjs introduces the ngModelOptions directive which gives you better control of when / how the model is updated from the view.

In my case, I needed to prevent the model from being updated until the user pressed ‘enter’, or until the input element lost focus.

Using ngModelOptions, you can specify which event will trigger the model update like this ng-model-options=”{updateOn:’eventName‘}”, so if you want the model to be updated when the input element loses focus, you need the update to happen on the ‘blur’ event; ng-model-options=”{updateOn:’blur’}”.

Note! If you want to prevent the ngModel directive from updating the model altogether, you can specify an ‘invalid’ value for updateOn, for example ng-model-options=”{updateOn:’none‘}”.

The next thing to do is update the model when the ‘enter’ key is pressed.To achieve this, you need control of when the ngModel directive updates the model. The API for the ngModel directive is surfaced through the ngModelController, so by getting a reference to the ngModelController, you can manually trigger a model update.All of this can be done using a custom directive which is applied to the input element.

Microsoft added custom markup extensions to SL5, but they did not provide built-in support for binding to the properties of CME’s. If you’re using CME’s to manipulate your UI, trying to make the UI react to changes in your View Model after the UI has loaded will not work.

When the UI loads, the runtime finds your CME’s and calls the ProvideValue method of your CME to get the value that should be applied to the UI element. The problem is that there’s no way to force the runtime to call ProvideValue again when something has changed in your View Model, so the UI will not react to changes in your VM.

Below is an example of how you could use a CME (called ConvertBooleanToVisibility) to toggle the visibility of a UI element based on the state of two properties in your View Model. Doing this without using a CME would require you to create a third “aggregate” property in your View Model to combine the values of the two main properties, bind to that aggregated property and use a ValueConverter to convert from boolean to Visibility.

As you can see, I’ve used a CME with two properties, Value1 and Value2, that binds to two properties in the View Model. When these values change, the Visibility property of the Rectangle is changed.

The trick to make this work is the following:

Instead of inheriting from MarkupExtension, you need to inherit from DependencyObject and implement the IMarkupExtension<object> interface

Add dependency properties to the CME, so that you can use bindings. The DP’s must have a property changed callback.

In ProvideValue, get a reference to the UI element and property that the CME is applied to. You’ll need these references to manually update the UI element when your View Model property changes. You’ll also need to subscribe to the DataContextChanged event for the UI element so you’ll know when a View Model has been attached. This is necessary because at the time the runtime calls ProvideValue the first time, the View Model may not yet be attached, so you need to modify the binding to point to the correct source once you have a View Model in scope.

When the View Model is attached, the DataContextChanged event will be raised. This will allow you to get the binding expressions for your dependency properties. To get the binding expressions for your properties instead of the values, use the ReadLocalValue method instead of GetValue(…). Once you have the binding expressions, copy the binding and remap the binding source so that it points to the attached View Model. Then apply the new bindings to the dependency properties of the CME.

Once the bindings are in place, this will make the property changed callbacks to get called when the dependency properties are changed. In the callbacks, call a method that calculates the composite value of the the two DPs and use the UI element and property reference obtained in ProvideValue (step 2) to update the UI element.

Below is a complete listing of the implementation of this Custom Markup Extension.

On this project I was working on, I had to monitor objects and object graphs for changes so I could display this information to the user. Having looked around the internet for solutions, I could not find any single solution that I felt suited my needs perfectly, so I decided to take a stab at the problem myself.

The requirements for my change tracker was the following:

Very easy to use, preferably a single line of code to enable and disable change tracking for an object and its entire object graph

The solution had to support an unknown object graph depth and automatically adapt to changes in the graph depth (attach to new objects added and detach from objects removed, including items added to and removed from collections)

Automatically listen for changes to all properties of objects, but support adding exceptions for properties that should not be tracked (if any)

Support explicitly defining which properties that should be change tracked

Except for implementing the INotifyPropertyChanged and INotifyCollectionChanged interfaces, there should be no other requirements imposed on the objects for enabling change tracking

Change notifications should be easy to subscribe to and contain data about the changes that had been made

To jump to the conclusion, what I ended up with was the following, which attaches to an item and starts listening for changes to the item and its entire object graph:

The first line of code creates an instance of the ObjectGraphObserver which starts listening for changes made to an object (“Item1”) and its object graph by passing in the object root as the first argument. The second argument passed to the method is the callback that should be called when a change occurs. In this case I call a method which dumps information about the change that occurs, but you could also do all other sorts of things like (conditionally) raising a dirty flag to indicate to the user that a change has occurred.

The DumpChangeTrackingInfo method looks like this. You can see I’m using the data passed along from the observer to provide some “useful” information to the user.

When an ObjectGraphObserver is created by passing the root object to the constructor, reflection is used to walk the object graph and setting up the change monitoring. By using reflection, you all know that this solution will not be extremely fast for setting up the change tracking for very large object graphs, but for my needs it was more than fast enough. I usually make sure to create the observers on a separate thread to not block the UI or other processes. The ObjectGraphObserver also has constructor overloads that lets you specify a max depth at which the observer stops tracking changes.

The ObjectGraphObserver passes two kinds of event args to the callback when a change occurs; the ObjectChangedEventArgs for changes to properties of an object, and the CollectionChangedEventArgs when a collection changes (items being added or removed). Both event args contains information about the object that was changed and which property of the object that was affected. The CollectionChangedEventArgs also contains information about the item that was added to or removed from the collection.

To prevent an object in the object graph that implements INotifyPropertyChanged or INotifyCollectionChanged from being change tracked, you can decorate a property with the NonChangeTrackableAttribute attribute. This will make the ObjectGraphObserver ignore that property when it walks the object graph. All properties of a type that implements INotifyPropertyChanged / INotifyCollectionChanged not tagged by the NonChangeTrackableAttribute attribute will be tracked (unless an explicit list of types and properties are specified, which I’ll demonstrate shortly).

The code snippet below shows an example of using the NonChangeTrackableAttribute attribute.

The above example shows how to set up exceptions for properties that should NOT be tracked. I also needed to support the opposite approach; explicitly specifying only the types and properties that should be tracked. Using this approach, only the types and properties explicitly defined in a mapping list are being tracked, all the other types and properties are being ignored.

The following example shows how to create an observer which listens for and notifies about changes made to the “Name” and “Count” properties of “Level2Item” instances. I’ve also set the max depth to 10, meaning the observer will not monitor objects deeper than 10 levels from the root object.

I’m not saying this is an ideal solution to the problem, but it works for good for me. There are issues regarding circular references that I do not handle. Also, the fact that I’m using reflection to set things up makes it “slow”, so if you’re planning on using the same approach, be aware of the implications of attaching to a large object (graph).

For a project I’m working on, we’re using WCF Data Services as our primary data service technology. We have created a small framework / pattern that extends the DataServiceContext and the entities being tracked, so that when any property of an entity is changed, that entity is marked as “Dirty”. When the user wants to save the data, we find the entities that are tagged as Dirty, and calls DataServiceContext.UpdateObject so any changes are can be saved to the database.

The implemenation seemed pretty straight forward, but we discovered that for some reason, not all the entities had its data updated to the database.

This is our first implementation of the ApplyChanges method that is called when the user performs a save action;

All this looks fine, but what happens when you call UpdateObject, is that the entity (or EntityDescriptor) being updated is moved to the end of the DataServiceContext.Entities collection, which means our loop state suddenly becomes invalid. I’m sure there’s a good reason for this behavior, it just isn’t obvious.

The fix is simple enough, use a foreach loop instead of the normal for loop, and everything works just fine.

This is a simple Silverlight behavior that can be used for providing a smoother UI experience when switching between two or more controls (any FrameworkElement derived component) by applying a fade in and fade out animation to the controls being switched. It can also be used to fade a control in when the UI is loaded.

The behavior derives from System.Windows.Interactivity.Behavior<T> from the Blend SDK, so you need the System.Windows.Interactivity.dll or the Blend SDK installed to run the sample.

The code is pretty straight forward, so I’m not going to go into that (you can download it from the link at the end of this post). Instead, I’ll just show the XAML for using it:

When the behavior is applied to a UI element, it will fade child elements in and out when the FrontElementName property is changed.The FrontElementName property is used for setting what UI element should be visible at any time, and the behavior searches the UI element for a child with a matching name. When it finds a match, it fades the new element in and the old element out.

The FrontElementName property is a dependency property, so it can be databound and have its value updated from a view model as the example below shows.

The other day I was writing a Silverlight custom control, deriving from Grid, I needed to get notified whenever the Children collection of the Grid changed. The problem is that there’s no collection changed event being raised when a UIElementCollection changes.

So I fired up .NET Reflector and found out that there acually is a changed event being raised when the collection changes, but it’s internal only. However, since the UIElementCollection Count property is a dependency property (UIElementCollection derives from PresentationFrameworkCollection<T>), you can listen for changes to the Count dependency property using an attached property trick.

For this purpose, I created a Rx extension method that lets you subscribe to dependency property changes. This way, I get notified whenever the UIElementCollection changes.

The other day when I was working on a Silverlight project I couldn’t find the ‘Silverlight UserControl’ template in the Add New Item dialog…it was simply gone. Also missing was the ‘Silverlight Templated Control’ template. I’m not sure what had happened, but I had recently installed the confusing GDR1 update to the Silverlight SDK…don’t know if that’s the one that caused the problem, but it’s my number one suspect.

When I looked in the Visual Studio ItemTemplateCache, I could see that the .vstemplate file for the Silverlight UserControl template was missing from the system. Somehow it had been deleted, and I’m 100% sure I didn’t do it.

To fix the problem, I had to delete the content of the ItemTemplateCache folder;