Moving from WPF to Silverlight (part 2)

---

Trouble appears when it's least expected.

---

Continuing from part 1 let’s go into the things that not only will require more coding effort but will also change the whole design of your app. And if you are managing a team then it’s two times more difficult because you have to stand all their whimpering. Let the party begin:

1. No default button! Long gone the simple WPF property on the Button class that was making it the default one for the page/form. What is even stranger though is that even in the web, typing in a textbox and then pressing Enter is the DEFAULT BEHAVIOUR!I mean why on earth someone wouldn’t provide this functionality on a web framework!
2. No double click!Let’s say you have a grid for your search results. No you have to click (select) a row on the grid and then move the pointer to another button which will actually get your selection and do something with it! No more double click on a row and get things done.
   
3. Focus on a control! So let’s say you move into a new screen and you want to focus on a textbox. It should be as simple as a method call right? m_myTextbox.Focus(). Weeeeeeell, this is probably not going to work!!! Yeah, you see it will work fine on a OOB application but on a browser app you need first to focus on the Silverlight plugin and then focus on your control! So you actually need something like:
   
   System.Windows.Browser.HtmlPage.Plugin.Focus();
         RegularTextBox.Focus();
   Or if it’s that you want to focus something on startup or on Loaded event then you have to call:
   

              Dispatcher.BeginInvoke(() => input3.Focus());

   Unbelievable right??
4. No keyboard typing selection in ListBoxes/ComboBoxes! This is another one that makes users’ nerves go high. Usually on both a desktop and a web app when there is a ComboBox on a screen you can start typing something and the ComboBox selects the item which has a text that matches the typed characters. There is no such thing in SL. The only acceptable solution I managed to find is to code a behavior that would select an item but only on the first typed letter. So if a user types three letters fast my behavior will execute three times selecting a different item each time.
   
5. Asynchronous world! This is the most serious one and that’s why I left it last. Probably most of you WindowsForms/WPF application designers have thought about pressing a next button, make some operations secretly from the user on another thread and then when that thread comes back actually present the next page. Well I have news for you! It’s not that easy anymore! Since every call to a delegate/callback/web-service/Agatha-rrsl method is ASYNCRHONOUS! What this means is that if you want to calculate something before going to the next screen and you want that calculation to be done on the server side then you have to somehow transform this call into a synchronous one as there is no way it can be inherently synchronous (there are a few very nice solutions out there, but I won’t get into the details). Just think of it for a moment. We are taking about some serious changes here, especially if you have a SOA with any kind of Service bus/WCF/asmx/Queue services talking to each other.
   

Most of the problems I described in these two posts can be solved with various workarounds. But the point is that most of these things should just work. We are talking about behaviours that are considered DEFAULT for a long time now and users are expecting them from your app.

All in all, I still remember the words of my old colleague about “how easy it should be” and seriously I am laughing! If it’s not a business critical requirement DON’T TRY IT! Just don’t!!! Think about it from the very beginning of the project and make sure you understand your domain and business requirements and of course never listen to an optimistic colleague! ;)