ailon's DevBlog: Development related stuff in my life

Side Effects of Silverlight Marketing

7/1/2010 9:47:07 AM

Note: this post is about marketing to developers (not general public).

Yesterday Tim Heuer published a blog post titled “Top issues for Silverlight” where he summarizes reported Silverlight issues. Apparently number one issue is “WPF and Silverlight feature (dis)parity”. Tim writes:

It’s a little weird to call this one an issue with Silverlight, but this was seen requested more often in these areas that it is worth calling attention to.  Some of the genesis of this angst comes from an expectation that WPF applications ‘just work’ in Silverlight and not understanding the areas of the subset in both XAML and the .NET base class libraries (BCL).

Now this is true but one has to wonder where this expectation comes from.

Silverlight is NOT a subset of WPF

The root of this problem (at least how I see it) is the initial marketing message of Silverlight for developers was that it is a subset of WPF. Now Microsoft is a serious and cautious company and you would hardly find any direct evidence of this but this is what gets stuck in minds of developers who know about WPF and/or Silverlight from various presentations before they dig deeply into development.

It’s hard for Microsoft insider to realize this. That is not that obvious even for someone who is working with both WPF and Silverlight. But if you take someone who does some real work with either WPF or Silverlight but not both and ask them what’s the relation between WPF and Silverlight, most of the time you are going to hear the mantra – “Silverlight is a subset of WPF”. I’ve heard developers, project managers, etc. with no experience in WPF and/or Silverlight repeat this numerous times. And that was exactly as I saw things before I started coding with both. This is encrusted deeply in the minds of developers and is the main source of frustration when they realize that this is not exactly the case.

I guess with all the advances in Silverlight over the recent years this disparity became a little more expected than before but the “subset” idea is pretty much still alive. Now I don’t know what needs to be done to kill this mantra and I’m not even sure Microsoft’s business departments want to kill it but I think this is the main source of this “issue” being number one.

Silverlight for Windows Phone 7 is NOT Silverlight

This subtitle is a little too drastic on my part but I’ll explain what I mean in the next few paragraphs.

One might think that WPF vs. Silverlight case was one of it’s kind but just this spring during MIX10 conference while unveiling Silverlight as one of the main developer platforms for Windows Phone 7 Scott Guthrie said this: “It’s not Silverlight Lite. It’s not Silverlight Mobile. It’s Silverlight.” (watch MIX10 Day 1 Keynote).

Now the wording is really clever. And later he explained that it’s Silverlight 3 with some parts of Silverlight 4 and phone specific stuff. He never said that you can run exactly the same code on the phone as you can on desktops and those who were interested in WP7 development understood that. But majority of the folks who just listened to this as high level overview have this notion stuck deeply in their minds. They believe that they can continue working on their Silverlight apps as they did before and then if they decide to move the app to WP7 they will only have to shuffle the UI a little to fit the smaller screen.

Do you think they are going to be frustrated when they find out that this is not the case? What do you think is going to be the top issue for Silverlight for Windows Phone 7? My guess is “Silverlight and Silverlight for WP7 (dis)parity”.

Shout it kick it on DotNetKicks.com

Quick Charts for WPF & Silverlight v.1.0 Beta Released

5/10/2010 3:48:46 PM

We are happy to announce availability of feature complete version of amCharts Quick Charts for WPF & Silverlight.

Quick Charts is an easy to use, fast set of charting controls for WPF & Silverlight. And it's FREE and Open Source (Ms-PL)!

Quick Charts for WPF & Silverlight

Quick Charts motto is: Ease of Use, Speed, Small Footprint. It is amCharts Bundle's little brother. It has less features, but concentrates on what's important for the majority of users. In order to achieve this we didn't just strip the features off of amCharts Bundle, but created Quick Charts from scratch.

Check them out and, please, spread the word. Thanks!

Shout it kick it on DotNetKicks.com

Debugging Silverlight Out-of-Browser Applications on 64-bit Windows

4/22/2010 3:53:52 PM

Today I had to debug a problem in my Silverlight 3 project that manifested itself exclusively in out of browser mode.

Here’s a concise and to the point guide on debugging Silverlight 3 applications in out of browser (OOB) mode by Jimmy Lewis. Problem is that when you follow it in Visual Studio 2008 running on 64-bit Windows 7 (and as far as I understand Vista too) you get this message box when you try to start debugging:

Warning: A StringBuilder buffer has been overflowed by unmanaged code. The process may become unstable. Insufficent capacity allocated to the StringBuilder before marshaling it.

I’ve tried to search for a solution on the web and all I found was a simple but not very satisfactory workaround: Use VS2010.

Yes, as far as I can tell the only way to debug your Silverlight 3 OOB app on Windows x64 is to open it in Visual Studio 2010. Problem is that first of all you need to have VS2010 and another problem is that it has to convert your project to 2010 format.

Luckily in my case I was able to just copy my VS2008 project to a new location, open it, convert it, quickly find a lame bug (I was assuming in one place that HTML Bridge is always available), implement single line fix and copy it back to my VS2008 project. So it was a small inconvenience in my case but if I ever need to debug something more substantial that could be a big pain.

However it’s quite possible that my googling skills aren’t perfect and I’ve missed a real solution to this problem. If so, please, let me know in the comments below.

VisualStudio.NET vNext Feature Request: Multi-target IntelliSense

4/8/2010 6:44:04 PM

Visual Studio is great. IntelliSense is great. But here’s one thing that has been slowing me down ever since I started developing for several .NET based platforms.

The Problem

WPF, Silverlight and now Silverlight for Windows Phone 7 are very similar frameworks, but they are far from being identical. Lots of code written for one can be re-used in another, but quite often it requires small modifications and it’s frustrating. It’s especially frustrating when you realize that those modifications wouldn’t be necessary if you’ve used another overload of some method or used another method altogether in the first place.

Take a look at screenshots of the IntelliSense dropdown for the same class in different environments:

Here’s one for WPF 3.5:

wpf_dropdown

And this is on for Silverlight 3:

silverlight_dropdown

Notice that there are lots of methods, properties and events that are not in Silverlight and I guess you can find some that are not in WPF (but that is not the point here). Sometimes you want to use WPF-only stuff for better performance or other very valid reasons but quite often you just use it unconsciously because finding out if something is supported in Silverlight or vice versa takes too much time and effort.

Now I wanted to add a LineSegment to the PathFigure and it has 3 constructor overloads in WPF

wpf_overloads

but only only the default constructor in Silverlight

silverlight_overloads

If I haven’t checked for the difference manually (or knew it by heart) I would end up rewriting this code once I’ve switched to a Silverlight project. So, you get the picture. The fact that I constantly have to recompile for all the platforms and/or manually check for differences takes a significant amount of my development time. I would like this to be addressed somehow and if some third party tool does something good in this area, please, let me know in the comments, but for now I have this idea/feature request for future version of Visual Studio .NET

Multi-target IntelliSense

There are numerous ways how this could be implemented and I’m not the best expert in things like this, but I’ll try to explain my vision of this anyway.

I think a project could have a set of secondary Target Framework settings. When these are set, IntelliSense would somehow highlight members or overloads that are in main target framework but not in the secondary. For example WPF methods that aren’t in Silverlight could be grayed out in the dropdown above. Same goes for method overloads. Plus some text explanation in the tooltip wouldn’t hurt too.

Something like this would be a huge time saver for me and I guess for other developers too. Especially with all the extra framework partitioning related to release of Silverlight for Windows Phone 7 which will be another very close yet not completely identical addition to the current mix of WPF & Silverlight.

I’ve ran this idea by Jesse Liberty at MIX10 and he thought it wasn’t a bad idea at all, so I decided I need to submit it to Microsoft via MS Connect. So if you like this and would like something along these lines implemented in the future version of Visual Studio, please, go there and vote it up.

Shout it

Ghost Lines in Silverlight

4/7/2010 4:30:00 PM

Some pretty strange bug in amCharts has been reported to me. In one scenario user got 3 graph lines when zooming-in deeply on a single line graph.

While investigating this bug I found out that previous data point in that scenario was far apart from the one in view and a line was drawn from that previous data point to the current one. The calculated X-coordinate of the previous data point was something around –89000 in my test case so I became curious if this a little crazy coordinate value could be the source of the problem.

I made a very simple Silverlight 3 user control with this simple XAML:

   1: <Canvas>
   2:     <Line X1="-50000" Y1="10" X2="500" Y2="110" Stroke="Green" />
   3: </Canvas>

Here’s what you get when you run this app:

image

 

It looks like even though X1 is supposed to be of type double it rolls over what appears to be Int16.MinValue limit. Tried this in Silverlight 4 RC with exactly the same result. Surprisingly (actually not surprisingly at all) this exact code works as expected in WPF.

Searching around the web produced a couple of results dealing with something that appears to be manifestation of the same issue but in different scenarios and with different outcome.

I wasn’t able to locate any mentions of these limitations in the documentation but I must admit I wasn’t looking hard enough to say that it’s definitely not there.

I’m not sure if I should report this as a bug somewhere provided that one of the posts above is on official Silverlight forums and there are no official answers to it. What I know is that we – Silverlight developers – have to account for this issue in our code and make required approximations ourselves (as in my case) or impose limits on users (as in cases above). So just beware of this oddity.

Some official or just informed word on the issue wouldn't hurt either.

Shout it kick it on DotNetKicks.com

MIX10K Winners on SilverlightTV

2/19/2010 10:13:15 AM

Yesturday John Papa and Adam Kinney announced MIX 10K winners on SilverlightTV. Check it out:

Get Microsoft Silverlight

The part about my entry starts at approximately 6:18 mark. And John accidentally hits a link to my games.ailon.org site. Oops :) I’m sorry, John.

I’m going to MIX10!

2/16/2010 11:10:44 AM

Thanks to all who voted for my MIX 10K Smart Coding Challenge entry. Thanks to you I’ve won the Community Prize!

image

I’ve already bought the plane tickets and I’m flying Vilnius – Copenhagen – Newark – Las Vegas on March 13th. Anyone on the same route? These are probably the most pleasant unexpected expenses of my life.

Congratulations to Grand Prize winner Jimmy D for his awesome Frog Log game made in HTML5 and to all runners-up!

I especially liked Pipe Runner by Rafal C – truly awesome game. You have to check it out. When I first saw it I thought I have no chances but I guess being an early bird paid off.

Thanks again to everyone who voted for my little game. You can download the source code of a slightly spiced up version here. It’s not a 10kb version and it’s not a good example of how you should develop Silverlight games (the beauty of code was not the objective) but it’s available for the curious.

Mix10_SeeYou_blk_240

If you would like to hook up at the conference or en route feel free to email me at ailon@ailon.org or message me on twitter @ailon or leave a comment here.

See you in Vegas!

MIX10K T-shirt

2/2/2010 12:44:44 PM

Got my Mix10K T-shirt Today:

Mix10K t-shirtMix10K t-shirt

Don’t forget to vote for my entry in the MIX 10k Smart Coding Challenge. You know, that’s the only chance I have of going to Las Vegas this year ;)

Tags: ,

Weekend project: Spiced Up Tic-Tac-Toe 3D

1/18/2010 2:41:56 PM

TicTacToe3D

Over the weekend I’ve spiced up my little entry in MIX 10k Challenge and posted it to games.ailon.org. Check it out. And vote for it in the contest. Thanks!

As usually source code is included, but… The objective of the initial project was to fit it into 10k and even though I’ve spiced it up visually I didn’t change the overall code architecture so it’s some pretty ugly code. Sorry :)

kick it on DotNetKicks.com Shout it submit to reddit

Tags:

Writing WPF/Silverlight compatible code. Part 6: Adding XAML files as links

1/13/2010 5:05:40 PM

Note for future readers: These series discuss WPF and Silverlight versions that are current stable versions at the time of this writing – WPF 3.5 and Silverlight 3.

These are ongoing series of posts on the subject of WPF/Silverlight compatibility. New posts will be added to the Table of Contents post as they are written so bookmark that post or just subscribe to my RSS feed.

While developing WPF/Silverlight applications and controls one of the main code sharing techniques is adding shared code files as links to one of your projects.

Visual Studio - Add As Link

This works perfectly with C# or VB files but not as good with XAML. In this article I’ll show you a workaround to make this technique work with only a small overhead.

The Problem

Suppose you’ve created a WPF project and your own custom control named MyTemplatedControl. It does nothing in our example (just sets DefaultStyleKey property).

   1: public class MyTemplatedControl : Control
   2: {
   3:     public MyTemplatedControl()
   4:     {
   5:         this.DefaultStyleKey = typeof(MyTemplatedControl);
   6:     }
   7: }

Now we create a default ControlTemplate for our control. To do this we add Themes folder to our project and Generic.xaml flie in that folder.

image

Our template will just display a blue rectangle (just so we can see if it’s applied). Here’s the XAML in Generic.xaml file.

   1: <ResourceDictionary
   2:     xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
   3:     xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
   4:     xmlns:local="clr-namespace:TestControl"
   5:     >
   6:  
   7:     <Style TargetType="local:MyTemplatedControl">
   8:         <Setter Property="Template">
   9:             <Setter.Value>
  10:                 <ControlTemplate TargetType="local:MyTemplatedControl">
  11:                     <Canvas>
  12:                         <Rectangle Canvas.Left="20" Canvas.Top="20" Width="100" Height="100" 
  13:                                    Fill="Blue" Stroke="Black" StrokeThickness="3" />
  14:                     </Canvas>
  15:                 </ControlTemplate>
  16:             </Setter.Value>
  17:         </Setter>
  18:     </Style>
  19: </ResourceDictionary>

We add our control to a test window and run the app we see something like this:

image

Now we want to create a Silverlight version of the control. We create a Silverlight custom control project, “Add As Link” our MyTemplatedControl.cs file, create Themes directory and “Add As Link” our Generic.xaml file. Everything compiles just fine. But when we add the control to a Silverlight application and run it we get an empty white screen. The template is not applied.

This happens because for some reason (I don’t know if it’s done for a reason or is it just a bug) XAML compiler compiles local and linked .xaml files differently. Here’s an article describing what happens. Short story is that resource key for local and linked xaml files are different and since the engine looks for a specific resource key for default styles it just can’t see the linked version because it’s key is not equal to what it looks for.

The Solution

The above mentioned LearnWPF.com article suggest a workaround of moving all resources to a separate assembly. I’m pretty sure that wouldn’t work with default styles and generally is not something you would want to do in simple scenarios.

I solved this issue using MergedDictionaries. The solution is to move you Generic.xaml content to other XAML file (or even better separate files for each control). This way you can “Add As Link” those specific files and add separate Generic.xaml files with only a list of MergedDictionaries addressing the resource key differences.

Let’s apply this technique to our example. So we move our XAML to a separate MyTemplatedControl.xaml file and reference it from MergedDictionaries in Generic.xaml.

MyTemplatedControl.xaml:

   1: <ResourceDictionary
   2:     xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
   3:     xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
   4:     xmlns:local="clr-namespace:TestControl"
   5:     >
   6:     <Style TargetType="local:MyTemplatedControl">
   7:         <Setter Property="Template">
   8:             <Setter.Value>
   9:                 <ControlTemplate TargetType="local:MyTemplatedControl">
  10:                     <Canvas>
  11:                         <Rectangle Canvas.Left="20" Canvas.Top="20" Width="100" Height="100" 
  12:                                    Fill="Blue" Stroke="Black" StrokeThickness="3" />
  13:                     </Canvas>
  14:                 </ControlTemplate>
  15:             </Setter.Value>
  16:         </Setter>
  17:     </Style>
  18: </ResourceDictionary>

Generic.xaml

   1: <ResourceDictionary
   2:     xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
   3:     xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
   4:     >
   5:     <ResourceDictionary.MergedDictionaries>
   6:         <ResourceDictionary Source="/WpfControl;component/Themes/MyTemplatedControl.xaml" />
   7:     </ResourceDictionary.MergedDictionaries>
   8: </ResourceDictionary>

Now we “Add As Link” MyTemplatedControl.xaml to our Silverlight project and add a copy of Generic.xaml and make required changes.

Generic.xaml (Silverlight project version)

   1: <ResourceDictionary
   2:     xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
   3:     xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
   4:     >
   5:     <ResourceDictionary.MergedDictionaries>
   6:         <ResourceDictionary Source="/SlControl;component/MyTemplatedControl.xaml" />
   7:     </ResourceDictionary.MergedDictionaries>
   8: </ResourceDictionary>

Notice the differences in Source of ResourceDictionary:

  1. It refers to out Silverlight assembly (SlControl)
  2. It addresses linked XAML file by it’s “incorrect” resource key which is a side effect of linking the XAML file described above (notice that there’s no “Themes” portion in the path)

Now our Silverlight app runs as expected:

image

This way we can share elaborate XAML between WPF and Silverlight versions (or just between several WPF and/or Silverlight projects) without having to maintain 2 versions of the file. And the only price to pay for this is that we have to add a line to both Generic.xaml files every time we add a new XAML file.

kick it on DotNetKicks.com Shout it
Copyright © 2003 - 2010 Alan Mendelevich
Powered by BlogEngine.NET 1.6.1.0