Infosys Microsoft Alliance and Solutions blog

« March 2008 | Main | May 2008 »

April 28, 2008

WPF ObjectDataProvider vs Direct Object Use

When using object instances in XAML, there are two ways to use them. One is to directly create them as resources, assign and key and use where ever required and other is to embed them inside of ObjectDataProvider and then use.

I have worked with both ways and was curious to know the differences between the two and benefit of using one approach over another. I can across this old blog by Beatriz that explain this very well. Along same lines, here is some discussion on XmlDataProvider as well.

April 17, 2008

WPF makes Designers and Developers friends again

I have been playing around with WPF for a while and have been blogging about some of the technical aspects on it. However today I will like to touch upon another important aspect of WPF and that is designer-developer connect.

Having worked on Windows Programming using C++, MFC etc for a decade and working with the various controls, it is a real pleasure to see the capabilities now available to WPF developers. It is true to a large extent that with WPF and XAML and the tools like Expression Blend, designers and developers can work lot more closely than ever before. The working closely is more towards the ability for designers to style the UI for the WPF application and the developers to write the code for it.

The WPF controls are called as look-less controls and the designer can do just about any type of styling on them. WPF does provide for a great design support for the controls and the look and feel of any control is only limited by your imagination. It can be argued that designers can take Expression Blend and sit on a beach, let their imaginations run wild and create an out of the world UI (whether anyone in this world will use it or not is a different question) and then come back and give the developers the XAML which they can then include in their VS solution and stitch the application logic to it and be good to go.

However, if only real life was this easy! Many a times the styles/templates defined by the designer are applicable at runtime since they may be set to apply on specific triggers like say mouse hover or button or item click etc. In such cases, for the designers to be able to succcessfully build the style and test it, they will need actual data to be able to run the application. Designers can temporarily use dummy data like embedded XmlDataProvider, but that means that during actual code build, developers will need to replace it with the real live data.

Another similar issue is with the designer being live. Not the designer as in person, he/she needs to be alive anyway, but the designer surface in Expression Blend or VS. What I mean to say is that the controls and data providers in the XAML are instantiated during design time also. This means their constructors are invoked and hence requires that the code behind work properly, else designer (person) will be stuck with errors that they may have no clue on how to resolve. See some of the typical design time issues here and here. One of the common ways to handle XAML load issues is to use the DesignerProperties.GetIsInDesignMode API and based on the return value, avoid doing some processing that may require the application to be in running state (if return value is true).

However I would say that these are probably still small issues when compared to the ability of styling the WPF applications. The UX development has come a long way with WPF, since the earlier thick client applications  (and with Silverlight for the Web). The designers and developers, by working closely, can really work wonders.

April 11, 2008

WPF Data Binding

WPF data binding a very effective way to bind .net CLR objects to WPF UI controls and ensure appropriate updates (by proper use of binding mode and property change notifications). However it can become a bit tricky if not used properly. I recently found these interesting 10 points about WPF data binding. I am sure you would find them helpful as well.

April 10, 2008

WPF - Passing string to ConverterParameter

There are enough online sources that talk about how to buid and use custom Converters in WPF and also how to pass parameters to these converters. However for some reason, all these examples tend to either use a single integer or a single word string. So recently when I had a need for passing a sentence as parameter, I was confused.

Fortunately the simple trick of using single quotes inside of double quotes to provide strings worked in this case as well. Following are two ways you can pass a string that has multiple words to a converter.

        <TextBlock Text="{Binding Source={x:Static sys:DateTime.Now}, Converter={StaticResource custConverter}, ConverterParameter='The time of the day is '}" />

Though VS color coding goes for a toss, the designer still loads fine and code also runs fine. If you use the more elaborate syntax for setting the binding, the regular double quotes will also work.



                <Binding Source="{x:Static sys:DateTime.Now}" Converter="{StaticResource custConverter}" ConverterParameter="The time of the day is " />



And the converter logic in this case is pretty trivial and is as below.

    public class DateConverter : IValueConverter


        #region IValueConverter Members

        public object Convert(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)


            DateTime dt = (DateTime)value;

            return parameter.ToString() + dt.ToLongDateString();



        public object ConvertBack(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)


            throw new NotImplementedException();




BTW, needless to say that you need to include the appropriate namespace for the DateTime.Now to work and that will be xmlns:sys="clr-namespace:System;assembly=mscorlib"

[Updated: April 25, 2008] There is another simple way to pass strings. First define a resource as below

        <sys:String x:Key="mystring">The time of the day is </sys:String>

And now use this resource for setting the value of ConverterParameter as below

        <TextBlock Text="{Binding Source={x:Static sys:DateTime.Now}, Converter={StaticResource custConverter}, ConverterParameter={StaticResource mystring}}" />

April 9, 2008

Why is .NET Micro Framework so crucial for Autonomous digital enterprise

"Let there be light!" And there was light.
"Let there be organized information!" So evolved ledgers and related recording systems, computers and applications.
Now in the age of digital nervous system, when we say "Let there be Automation!" , Information flow should address the whole spectrum of source, relation, content and target. Right from the days of hurricane lanterns till now, source of light has been an integral part of almost all the gadgets be it torches, mobile phones or big ones like street lighting systems or trains or even huge A320 airbus that fly about.
Just as a light source has become indispensable in all these gadgets and systems, the future years would see  miniature devices, microcontroller, sensors proliferating in alomost all space, be it domestic, automotive or retail…almost all that we could imagine!
Microcontrollers and sensors will become an integral part of almost all gadgets. To make them collaborate amongst them and other applications is the challenge!
Let us take an instance of a temperature sensor in a hard disc, which needs to monitor the temperature.In case of an abnormal situation,it needs to discover a target (device/application), and know if it can address the situation and send information to the target and invoke some service in the target, say capture the snap shot image of the media and store in a recovery mirror.
In order to achieve this i.e. to program the sensor, at least,
1. You need a base operating system to host your logic which discovers and invokes services.
2. You need to define communication mechanisms.
3. You need good enough space to place your binaries, operating system files and the kernel.
Now, how do you accommodate all the above in a temperature sensor processor which can at most have a few 100 KBs of memory?
.NET Framework with its miniature size and its ease of getting hosted and powerful programming model with high level programming language like C#, makes it possible. .NET Micro Framework does not need an operating system as it comes with a small bootable run time host for the CLR, It uses DPWS which is a  service oriented discovery and service invocation paradigm also it can take advantage of RF based communications as well.
.NET Framework - its big brother, other complementary technologies like Windows CE and XPe which are hard real-time embedded, Windows Embedded for Point of Service systems, enables devices built on .Net Micro Framework to easily integrate and communicate with enterprise scale applications and vice-versa with seamless mobility.
.NET Micro framework has a huge potential of bridging the gaps  between tiny devices and other devices, applications and thereby connecting islands of information and holding the key to future autonomous digital enterprise.
And looking into the effort part of it
1. What would be the effort in programming in a legacy programming paradigm for embedded systems?
2. What would be the effort to debug them? Etc.
With state of the art development environment from Microsoft, development
and debugging efforts are radically less as seen in “Leviton Manufacturing” case study in my previous posts.  
Visual Studio 2005 and higher versions provide best of the class IDE for programming the .Net Micro framework and debugging capabilities. Whether programming an emulator for the device or direct deployment to the device, it is all just clicks away.  

April 4, 2008

WPF - Binding to Image Control

Overtime, I have used different approaches to binding pictures to Image control in a WPF application. I have seen various questions on the WPF forum as well on this topic. The information is all available out there, but scattered. Hence, I decided to create a sample application to demostrate the various scenarios that can exist when you need to use the Image control to display pictures.

You can download the demo code (Download file) and play around with it. If you unzip it in C:\, it should work without having to change any file paths etc. There are 7 scenarios that i have currently handled in code. If you can think of more, do pass them along and I will update the code to add them as well

  1. Regular resource image binding to Source property in XAML
  2. Binding resource image, but from code behind
  3. Binding resource image in code behind by using Application.GetResourceStream
  4. Loading image from file path via memory stream (same is applicable when loading blog image data from database)
  5. Loading image from file path, but by using binding to a file path Property
  6. Binding image data to a user control which internally has image control via dependency property
  7. Same as point 5, but also ensuring that the file doesn't get's locked on hard-disk

Comments welcome !

April 3, 2008


ASP.NET AJAX is come a long way since its inception a few years back and my personal take it is that it in a hype cycle right now, where everyone is trying to jump on-board and create AJAX based applications. Needless to say that it has its own benefits, but there definite downsides to it as well. You can read a set of 10 important aspects around AJAX here.

It is known that though it gives a flicker free UX, the under-the-hood story tells a different tale. Having read about it, some days back, we did a small experiment to really see the kind of differences one can get with different approaches and you can read about our findings in this report (Download file). The scenario we took is very simplistic, but the results are still eye-opening.

April 1, 2008

Satire: Harri Developer and the Knowledge of Domain

This is a sad story. So please do not laugh.

Harri was born a developer. People say, the baby was born with a Silverlight spoon. When he was three weeks old, he wrote his first ‘Hello World’ application.

XYZ Inc. hired him instantly. In just another fifteen years, he would report to XYZ Inc., as the youngest developer to lead their trillion dollar initiatives. His overjoyed parents poured him with affection, taught him his first alphabets – A, B, C – A for Address, B for Binding, C for Contract;  and the next three alphabets – W, P, F. “Gimme code, gimme code”, he would mutter in his baby talk whenever he felt hungry. His parents fed him imported coffee from Java served in a Shell decorated with Ruby, and he had a massive appetite.

Fifteen years later...

He stepped into his office where he was recruited fifteen years ago, with drumrolls and trumpets. He was shown his high tech cabin where he paused to look around and took his seat. ‘Gimme code, gimme code’, he said in his deep throated adolescent voice. The big guy at XYZ Inc., introduced him to Mr. Finpert, who was their expert in all financial affairs. ‘Mr. Finpert will take you through all the requirements of our trillion dollar initiatives. You have eight months to create a software that will do magic and is customizable enough for any future miracles that may or may not happen. ‘Gimme code, gimme code’, Harri kept saying. Mr. Finpert was amazed at this prodigy and wasting no further time, quickly took the seat beside and started explaining.

“The software you’ll build will serve international banks and insurance companies to adapt to changes in their environments, as well as manage risk and ensure regulatory compliance. Here’s how...”. Thus spake the master.

The next few hours the prodigal developer was disillusioned by the wrath of his own genius. What he was hearing wasn’t part of any language his parents taught. While he wanted to hear what’s public and what’s private, what’s the service, what’s the controller, what’s input, what’s output, Mr. Finpert was bragging about some guy called Dow Jones and why we should worry about him. The shock was imminent and he suddenly started feeling strange in his head. As the prodigal developer, he knew what that meant – he was having a memory leak.

The lesser technical Finpert’s words sounded, the more his memory leaked. His eyes were reduced to a mere pixel, and he could barely see. He fell face first and crashed into a carton of hard disks.

Moral of the Story: You may be a born developer, but without Domain Specific Languages, software development only becomes harder.

Inference: (Er, on a more serious note) Just understanding the technical nitty-gritty can only go so far. When the perspective of “Domain” is absent, the resulting software would always be far from the ideal.

In the next post I’ll discuss more on the “Domain” perspective of software development.

Subscribe to this blog's feed

Follow us on

Blogger Profiles

Infosys on Twitter