Portable Class Libraries, Pain level 5

While Portable Class Libraries are great in theory for sharing code across Win8 and WP8, in practice they’re severely limited by the classes which can be referenced.   The BCL should be segmented at a lower level to make simple non UI classes like Point and Rect available.

IValueConverter incompatible, Pain level 3

Win8 seems to randomly break IValueConverter by making the last parameter a string instead of CultureInfo!  I haven’t found the correct way to fix this, but at least this compiles Win8 and WP8:

public class BooleanConverter<T> : IValueConverter

{

    public BooleanConverter(T trueValue, T falseValue)

    {

        True = trueValue;

        False = falseValue;

    }

    public T True { get; set; }

    public T False { get; set; }

    public virtual object Convert(object value, Type targetType, object parameter, string language)

    {

        return value is bool && ((bool)value) ? True : False;

    }

    public virtual object ConvertBack(object value, Type targetType, object parameter, string language)

    {

        return value is T && EqualityComparer<T>.Default.Equals((T)value, True);

    }

#if !WINFX_CORE

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

    {

        return Convert(value, targetType, parameter, "");

    }

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

    {

        return ConvertBack(value, targetType, parameter, "");

    }

#endif

}

Platform fragmentation, Pain level 7

Sure, any platform over time will begin to fragment, but Microsoft seems hell bent on ensuring minimal portability of source code across their recent platforms. Whereas 1992 source code written for Win32 can be recompiled and run without modification throughout the intervening years, the same cannot be said of code written for Silverlight, WPF, WP7 and now Win8 and WP8.  

The half life of supported development platforms has fallen precipitously.  Silverlight, dead.  WPF ailing, WP7 obsolete, and the newcomers Win8 and WP8 proclaiming themselves the new shining path going forward. 

But developers are now gunshy and looking elsewhere, having learned through painful experience that Microsoft seems unable to commit to a coherent, long term development strategy.  Presumably this is an outcome of the org chart from the last decade:

One would have hoped that C# and the painfully verbose XAML would form the foundation of the future, but then COM and  C++ were confusingly resurrected, and we’re all invited to enjoy sprinkle our code with pointy hats:

 task<IVectorView<StorageFile^>^>(picker->PickMultipleFilesAsync())
      .then([this, uri]  (IVectorView<StorageFile^>^ files)  

Or we can learn the joys of non-typesafe code by switching to javascript and CSS for coding our Win8 UI (but not WP8!).

Since C#, javascript, and C++ and associated controls and libraries aren’t compatible for developing applications across Win8 and WP8, the future for Windows developers will be one of continued pain. 

…none of the crazy you get from too much choice.

Windows 8 and Windows Phone 8 Pain Log

I’ve been a Windows developer for just about forever, and since my pain threshold has just been exceeded attempting to port existing code to these new platforms, I’ve decided to share my agonies as a form of therapy.

Each item will have an associated numeric Pain value of  1 to 10, with 10 being extreme, out of one’s mind pain.

This should be fun!

Google Video Chat disables other capture applications

Since I recently stumbled back into video capture work for a client, I thought I should bring to light an annoyance with Google Video Chat that caused several moments of consternation.

Google Video Chat installs fake Direct Show video capture drivers (Google Camera Adapter 0 and Google Camera Adapter 1). Although these drivers are registered with DirectShow as functioning capture devices in the category CLSID_VideoInputDeviceCategory they are in fact not available to applications other than Google Video Chat and return errors when they are instantiated using normal DirectShow conventions. Since many programs (including the one I’m in the process of writing!) weren't written to handle the case of a registered , but non-functioning capture device, they fail in various ways, not to mention the general confusion of having a bunch of non-functioning entries in device selection lists within the program.

Since this problem has been known for over a year now but has not been corrected, should one assume that we are witnessing an attempt by Google to undermine the functionality of alternative video capture applications for their own benefit? Evil or not evil, you decide!

The simple fix which would be trivial for Google to implement is to not register the Google Camera Adapter in the CLSID_VideoInputDeviceCategory category.

References:

DirectShow App Mess: Google Video Chat vs. Skype
http://alax.info/blog/1233#more-1233

Hardware/Software issues
http://luizgustavo.wordpress.com/2011/07/30/hardware-and-software-issues/

Google camera adapter causing problems with other programs
https://groups.google.com/a/googleproductforums.com/forum/#!searchin/chat/%22google$20camera$20adapter%22/chat/MygYu9bo_hw/xfCcgy1p2zMJ

GOOGLE CHAT CAMERA BLOCKS MY REGULAR CAMERA
https://groups.google.com/a/googleproductforums.com/forum/#!searchin/chat/"google$20camera$20adapter"/chat/mIXdZWBGOKw/oewf2rIZ1TQJ

Google Camera Adapter shows up as a source when it is not
http://www.tech-archive.net/Archive/Development/microsoft.public.win32.programmer.directx.video/2009-10/msg00026.html

How to uninstall "Google Camera Adapter 0" and "Google Camera Adapter 1"?
https://groups.google.com/a/googleproductforums.com/forum/#!searchin/chat/"google$20camera$20adapter"/chat/5C-JcQjQA7Y/TcHusD0iX3sJ

Silverlight 2.0 and facebook

I decided to figure out how easy it would be to embed DeepZoom within facebook as an application.  After wasting most of the day learning to configure IIS7 applications for debugging and downloading and installing toolkits and starter kits, I finally figured out that all this rigmarole is unnecessary if you don’t need to access the facebook API and just want to embed your Silverlight app.

If you have a working Silverlight 2.0 application working within an .aspx page and you want to embed it into facebook, all you really need to do is add a few lines to your web.config file and then set up the facebook application to reference your existing web site.

The lines to be added to web.config are:

<appSettings>
      <add key="APIKey" value="GetThisFromTheFacebookAppConfigPage"/>
      <add key="Secret" value="GetThisFromTheFacebookAppConfigPage"/>
      <add key="Callback" value=”http://www.deepzoom.com/default.aspx”/>
      <add key="Suffix" value="MyIFrameApp"/>
      <add key="TemplateID1" value="20889707566"/>
      <add key="TemplateID2" value="20889902566"/>
</appSettings>

(I have no idea what the last 3 lines do either.)

The facebook app needs to be setup with using an IFrame and needs to have the Callback URL and Canvas URL set according to the instructions here.

If you want to go to the next step and actually access the facebook API, then you’ll need to follow the lengthy instructions at:

Facebook application development in ASP.NET

How to Build Facebook Applications with Silverlight 2 RTW – Part 1 of 2

How to Build Facebook Applications with Silverlight 2 RTW – Part 2 of 2

Embedding DeepZoom in FaceBook

It turns out it’s pretty simple to embed a Silverlight control in a FaceBook page.  Here’s the result.  Visit http://apps.facebook.com/nauticalcharts/ to see DeepZoom live.