Posts Tagged ‘Workarround’

HowTo: Open page from Internet Explorer (Metro) app into desktop IE

The Windows 8/8.1 app version of Internet Explorer is also known as IE Metro because of the “Metro” codename (inspired by navigation signs in public transport] of the Modern UI design language promoted by Microsoft).

However that version isn’t the full Internet Explorer, in that it is unfortunately not supporting extensibility via plugins in the form of ActiveX controls as the classic (desktop version) of IE. It is only embedding the Flash player engine directly in its codebase, but not Microsoft’s own Rich Internet Application (RIA) rendering engine aka Silverlight, nor Unity or other VRML/X3D, QuickTime/QuickTimeVR etc. plugins.

Browser pages cannot detect the difference between running IE on the desktop or as an app, there is however a workarround for webpage authors or webadmins to force the app version of IE to show a prompt to the user that allows the opening of a page in the desktop version of Internet Explorer. There is also a way for System Administrators to set specific sites to open in the desktop version of IE without the user seeing such prompt.

At, Microsoft mentions:

As a web developer, you can enable the requiresActiveX feature switch either by using this HTTP header:

X-UA-Compatible: requiresActiveX=true

Or by using this meta element on each affected webpage:

<meta http-equiv="X-UA-Compatible" content="requiresActiveX=true"/>


I just added the meta tag inside the <head>…</head> block of the Amnesia of Who web version that uses Silverlight and here is how it shows in the IE Metro version (note that Silverlight IS installed in that Windows 8.1 machine, it’s just that it’s not available in that browser, that’s why the Silverlight installation prompt is also shown):


When the user presses the default button “Open on the desktop”, the OS switches to classic desktop mode and shows an Internet Explorer window with the Silverlight application starting fine (or if Silverlight is not installed it will prompt and allow the user to install it – note that Silverlight ActiveX control’s installation doesn’t need administrator permissions since that installation doesn’t affect other users, nor requires any elevated rights in the system to work).



I hope that Microsoft, apart from keeping on supporting this workarround, will do a clever move this time and embed Silverlight too (apart from the Flash engine that was in IE Metro) in the Spartan browser that it prepares as the Windows 10 default touch browser. And why not, provide some extensibility method for it, since HTML5 cannot become a huge, impossible to implement beast, that covers every future conceived functionality for the web.

Fix: Hypelinks not clickable in RichTextBox under Silverlight

Just fixed a nasty bug in ClipFlair Studio (, where one couldn’t click hyperlinks in the Text component when set at ReadOnly mode. In that mode hyperlinks should open up new web pages (in Edit mode you can edit/remove them only of course), but instead when clicked they would show something like a focus rectangle (which they normally never show).


The situation was hard to debug since it wasn’t obvious what had caused the issue (it was working some time ago). I eventually found out that when the RichTextBox in Silverlight (may occur in WPF and WinRT too, haven’t tried) has a Transparent background, then Hyperlinks in it let MouseLeftButtonDown events pass through, so OnMouseLeftButtonDown will fire at their visual parent (or other visual ancestor) if no component in the visual chain marks the event as handled (such events bubble up towards the top of the visual hierarchy/containment chain).

This shouldn’t be much of a problem, if there wasn’t another issue, where if the ancestor called CaptureMouse in their OnMouseLeftButtonDown overriden method (from Control class), which is usual in mouse dragging code (in my case it was a FloatingWindow [TextWindow] that was the visual ancestor of RichTextBox), the hyperlink fails to fire when clicked and shows that weird solid-line border arround it instead.

The fix was easy once I knew what was happening, I attached a MouseLeftButtonDown event handler to the RichTextBox (if one was subclassing it [assuming it allows to do so] they could also have opted to add an overriden OnMouseLeftButtonDown method) that sets Handled property of the event parameter to true to consume it. The fix is available at CodePlex.

One can verify that the fix works now by downloading a sample ClipFlair Activity from and opening it in ClipFlair Studio. Can also download and build/run the source code of the previous broken version 1faaa8b35749 and test with that save activity file to see that the URLs didn’t open before when clicked but showed a rectangle arround them intead.


HowTo: Tell IE to use compatibility mode without editing your web pages


one reads:

We are using Telerik’s rich text editor (RadEditor), and it seems that RadEditor has specific behaviour regarding insertion of break tags.

To circumvent this issue please try to add host header in ISS 7 (website level):

Name = "X-UA-Compatible"
Value = "IE=EmulateIE10"

Or, you can insert Html Meta tag on a PreRender event (of Page that uses RadEditor):

HtmlMeta meta = new HtmlMeta();

meta.Attributes.Add("http-equiv", "X-UA-Compatible");

meta.Attributes.Add("content", "IE=EmulateIE10");



This is a very handy trick, one can open up a website at IIS console and open HTTP Response Headers node and then add the Name / Value pair X-UA-Compatible / IE=EmulateIE10 to force say Internet Explorer 11 to behave like Internet Explorer 10

To confirm it works, press F12 to show developer tools in IE11 and see at the right that it says “IE10” instead of “Edge” at the HTML engine selection dropdown list (compatibility mode).


Screenshot 2014-08-22 19.05.29

Gotcha: Silverlight’s Uri class constructor eats up part after last slash

Via trial and error, I recently found out that when creating a Uri combining another Uri and a suffix part (tried at Silverlight, but I guess it’s a .NET issue in general), it eats up the last part of the (first) Uri if it doesn’t end with "/".

That is, if you combine with b.doc you get instead of that one might expect having used the Path.Combine of .NET on the local filesystem before (if hope I do remember well how that one behaves). So you have to make sure the first part of the path you combine has / at the end (e.g. in the case above).

Personally I feel this is a bug at Uri class (since it breaks the least surprise principle [for developers with desktop experience at least]), but it may have been made so to follow some W3C suggestions or Javascript standard behaviour or whatever.


The following code will eat up part after last / (that is Uploads) instead of appending / (as Path would do on Windows).

const string STORAGE_URL = ""; //error: need "/" at end
Uri fileUri = new Uri(new Uri(STORAGE_URL), fileName + ".wav");

So, one can use instead:

const string STORAGE_URL = "";
Uri fileUri = new Uri(STORAGE_URL + "/" + fileName + ".wav");

Else fix the STORAGE_URL at the first sample to have "/" at the end (but this can break easily by changing the URL in the future and forgetting to add the trailing / or reading it from some configuration file and having the user enter a URL without a trailing / which can easily occur)

%d bloggers like this: