Microsoft Momentum 2009

Last month there was an MS event going on in Cyprus, Momentum 2009.  Being different from previous events, this one seemed to me as the best until now.  If nothing else but because of the venue where the event took place.

Usual MS events in Cyprus are 'played' at the hotel conference rooms while this year's Momentum had a full-size Hall within the Cyprus State Fair exhibition area.  Professionalism was on their side this time.

From the side of the CDNUG, we kept the Developers track (there was IT track going on in parallel) together with Karl.

I talked about Windows API CodePack and all nice UI goodies in Windows7.

Artemis has more details about the event and his session here.

General Dev. track review can be found on the CDNUG website here.

Desktop app and Paging the results list

Probably something you have been burned with in the past, while working with the potentially large sets of data, was the efficient display methods. Ever since I started playing with the WPF and the powerful binding it brings, I have faced poor performance when binding substantial result sets to a ListBox for example.

Then, the virtualization comes along: being able to allow platform to render just the required number of results that are visible at the specific point of time provides much better results. I must admit that it was a cumbersome process at first, but the results were impressive and that made me understand the virtualization sooner than expected.

Now, since the problem with the performance is solved, we are good to go! But not so soon. Lately, I've hit another wall: filling the source with the data usually is what takes time and while pushing the hard work to another thread may give some more responsive UI, I have been (once more) challenged to look for a solution. The problem this time was the relatively slow response from the server and the data arrival was delayed due to many factors (net congestion, busy server, bad scaling, etc) so for the larger result set it would have rather disappointing results.

It may sound like a myth, but everyday Joe really does have kind of fate in the desktop apps when it's about speed. Things open instantaneously, response is short and in an event when there is a 1 second delay - it does not look nice. Trying to explain that the 10-year old MS Access app was much simpler, not scalable and insecure - doesn't improve the situation. Speed and response still remains an issue.

While that same everyday Joe "expects" the desktop app to fly, he/she has a completely different opinion when using the web based apps. The delays are expected (there were delays from the start), poor response even improves lately mostly due to the higher bandwidth or some AJAX here and there, but in essence, there are no complaints and things magically *work*.

One interesting point that we have had discussed within the team was how to tackle our problem of the slow server response while maintaining the UI speed and responsiveness? So, we thought about doing exactly what the web apps do when there are large result sets: page it!

Now, this was a challenge in the WinForm apps and the already familiar DataGrids (which are de-facto standard for the business desktop apps from the "battleship gray" era) were never designed to do so. Users always expected to see "everything" in a single shot, being able to sort, group, filter and whatever-else with a single mouse click. Adding paging to any of the DataGrid variants (third-party mostly) simply does not seem natural.

In WPF it seems like a good opportunity to re-arrange the user's opinion. While using some new ways of presenting the data that is far, far better (and different) from the battleship-gray style, we have a unique opportunity to bring results paging into the desktop apps. And the end-users seem not to complain! For them, a WPF app seems like a completely new experience and they are "easier" to accept new stuff. That is, provided that it still allows them to do their job.

CDNUG community event

After so long time I've finally attended the latest CDNUG event on last Tuesday. It was good to meet and talk with Artemis and Evangelos.

Artemis spoke about Entity Framework and we all participated in the numerous demos.

I liked the exercises with the LINQ capabilities in combination with the Entity Framework.

XElement.Value and the new line hell

Ever since I tried XElement, it always made me anxious when I had to workout few lines with the good, old System.Xml.XmlNode. Thanks to LINQ, we got these nice X* family of classes that are so much more easier and helpful.

Recently, we've moved the parts of our cache initialization methods to use XDocument and XElement instead. Some of the cache type classes contain multi-line strings usually displayed in a WinForms TextBox. Accessing the content of an element is simple as using the Value property.

textBoxNotes.Text = MyNode.Element("notes").Value;

In fact, everything works as expected, except the multi-line text. Property Value getter trims off the "\r" character from the string (which is required for the TextBox to actually show the text in the new line) and the lines appeared glued to each other in a single line.

Haven't found anything on this issue yet. It seems annoying to use:

Element("foo").Value.Replace("\n", "\n\r");