Archive for June, 2010

How to bind a cutom property to user control in WPF

June 29, 2010

<UserControl x:Class="RMSControlLib.Resources.BevelBox"
d:DesignWidth="30" d:DesignHeight="30">
<Border x:Name="Box"
Background="{Binding ElementName=RootControl, Path=FillBrush}"/>


How to inherit from a typed style in WPF?

June 28, 2010

<Style x:Key="ThumbViewCloseBtnStyle"
TargetType="{x:Type Button}"
BasedOn="{StaticResource {x:Type Button}}">
<Setter Property="MinHeight" Value="0"/>

MVVM: Take One

June 26, 2010

I am wrapping my head around MVVM (Model-View-ViewModel) these days. Although I am a totally newbie to .NET, I’ve found it a very good thing to relate it to my experience with Flex SDK, as it gives me a deeper understanding about the thinking behind UI development. John Gossman from Microsoft has an awesome article about “MVVM“; Paul Williams from Adobe also has an awesome article about “Presentation Model“. Here is Martin Fowler’s article about “Presentation Model” that Paul refers to.

“ViewModel could be seen as a specialized aspect of what would be a Controller (in the MVC pattern) that acts as a data binder/converter that changes Model information into View information and passes commands from the View into the Model. The ViewModel exposes public properties, commands, and abstractions. The ViewModel has been likened to a conceptual state of the data as opposed to the real state of the data in the Model.” Basically ViewModel is a specialized representation of Model that is designed to manipulate View in a way that’s more friendly to the user mental model of the data (or in another word, how the UI is presented). Changes in the properties of ViewModel and changes in View are coordinated via data binding, mostly conveniently done declaratively.  These kind of “out-of-the-box” plumbings of Flex and WPF have freed the developers from having to deal with lower level of View manipulation using code, instead help them to focus on thinking in terms of user mental model, application flow and user interaction. There is this statement that ViewModel and View are completely decoupled, which I don’t agree. ViewModel is an adapter from the Model to the View; If the UI or user flow changes, the ViewModel has to change accordingly. Say you are building a “shopping cart” app for books that’s used on a small screen device. Users chooses “language”, “genre”, “year” and then “prices” consecutively which leads to a result of matching books (or no matches). You may use a ViewStack to display the options at each stage so that only one set of menu is presented to the user at a time. In your ViewModel, you may have the following:

public static CRITERION_LAN_SET:int = 0;
public static CRITERION_GENRE_SET:int = 1;
public static CRITERION_YEAR_SET:int = 2;
public static CRITERION_PRICES_SET:int = 3;
[Binding] public var selected_criterion:int;

/**Hook to a “Next” button or an item in each of the aforementioned selection menu so that when the user taps on it, the ViewStack can advance to the next menu */
[Binding] public function addToSelectedCriteria():void
if(selected_criterion < CRITERION_PRICES_SET) selected_criterion++;
<mx:ViewStack selectedIndex=”viewModel.selected_criterion”…/>

So if you decide to have a desktop version that can present all the selection criteria at a time as opposed to one by one, you will then no longer need addToSelectedCriteria() or selected_criterion in the ViewModel.

Data binding is an adapter in declarative UI programming which enables developers to program in higher level when dealing with user interaction. Without the plumbings provided by data bindings and commands, etc., you would need to manage UI states directly with “code” that manipulates the View — but you would probably prefer to delegate this kind of lower level manipulation to more specialized objects, as opposed to dealing it directly with your ViewModel — while with Flex and WPF, you delegate these tasks to the framework.

In conclusion, the whole point of all these fancy patterns still nails down to the very basic stuff about programming, things such as breaking down different levels of tasks into different layers and chunks of code, such that your code maintain a hierarchical structure in terms of abstractions (called “decomposition” or “stepwise refinement”). This results code easy to understand, maintain and modify. It’s worth pointing out as we step back for a moment to take a breath and look at a bigger picture.

Why Label is considered Control

June 11, 2010

“A label is considered to be a control because of its support for mnemonics (shortcut keys that transfer the focus to related controls).  A tooltip is considered to be a control because it appears and disappears depending on the user’s mouse movements.” – Pro WPF in C# 2010 Windows Presentation Foundation in .NET 4, Matthew MacDonald.

For example, a Label can allow a user to access a menu by typing the “menu mnemonic“.