No Syntax Highlighting On Preview In Live Writer 2011?

Anyone using my Windows Live Writer plug-in for Source Code highlighting will find that after upgrading to the latest Live Writer version the preview feature is not working. The latest version of Windows Live Writer that ships with the Windows Live Essentials 2011 package has some modifications to prevent script running from within the application. This is apparently to enhance security and whilst I think that this modification is a valid one on those grounds I would have expected a way of the user being able to disable this feature.

On the previous version of Live Writer on inserting a code snippet you would get a nice preview (left hand image) but now in 2011 you just get the plain text version of your code (right hand image):


My plugin uses JavaScript (for preview purposes only – it’s not posted to your blog) to render the code exactly as it will be displayed on your WordPress blog but as this script is now disabled no render can take place.

To be honest I am not a fan of the new Live Writer as to me it appears as though the only objective was to get the ribbon toolbar included at the expense of most other things, including usability. To insert anything now I have to select insert on the toolbar and then select for example an image. Previously I just clicked on the right hand toolbar. The way that the plugin buttons are displayed on the toolbar is also poor in comparison to the previous version.

Regardless of seeing it as a step backwards I do intend to support this version with my plugin and so will be releasing an updated version soon that will aim to provide some sort of preview functionality within 2011 (although I expect it to not be as convenient as with the previous version). 

Stay tuned for the next version.

Live Writer Syntax Highlighting Plug-in v1.2.0 Released

I have finally posted a new version of my Windows Live Writer Syntax Highlighter for hosted blogs, you can find it here. Version 1.2.0 has been a while in the making but I have included the features most requested by you guys. Firstly thank you to everyone who had downloaded the plug-in and provided feedback either directly on this blog or on their own blogs. I do take the feedback seriously and have included all the features that I could into this version.

So what’s in V1.2.0? Well there are some small bug fixes and improvements which you may or may not notice, but the big features are covered below:

Ever since the first version of the Plug-in I have wanted to provide a mechanism to preview what the syntax highlighting will be like once the post has been posted to your blog. The problem is that the rendering is done not by my plug-in (as it just inserts the right tags into the HTML) but by the WordPress server. After a few ‘proof of concepts’ I finally hit on a way of making this work. The result is that you can see what your code will look like in both the ‘Edit’ and ‘Preview’ windows within Live Writer (see below screenshot):


This preview mode can be turned on/off per code snippet too. Any changes to the code snippet properties, for example to highlight specific lines, will take effect in the previewed version too so you can get a feel for how the properties affect the snippets display. It should be noted however that to refresh the preview display you will need to switch to the ‘Source’ or ‘Preview’ views in Live Writer and back to ‘Edit’ view. This is purely due to the fact that Live Writer doesn’t refresh the view after altering a plug-in item.


The code entry form (above) has been upgraded to accept tab inputs, be movable and now provides a line/column number indicator. It’s very useful to be able to identify lines and columns so that you can choose the right line to highlight and can ensure that you are within any relevant width restrictions on your blog for the code snippet. The context menu on the code entry form also has a ‘Trim Whitespace’ option which will trim the leading and trailing whitespace from your code snippet. This is useful after you have pasted in code from another editor, e.g. Visual Studio.

The issue of XML not being displayed correctly has been resolved. This is again a Live Writer limitation as it will not display HTML or XML correctly. This is resolved two ways in this version of the plug-in. Firstly when you use preview the XML/HTML will be displayed correctly as it is fully rendered to look how it will look after posting. Secondly where you have chosen to turn off preview the plug-in will now replace the “<>” characters with “()”. This change is purely for viewing in Live Writer and the correct characters will be used when posting to your blog.

Version information and a check for updates link has been added to the ‘Tools – Options – Plug-ins’ dialog (see below). I hope to introduce the option of auto updates in future versions, but for now the link just navigates to the plug-in’s homepage.


You can download the new version from I hope you like it.

New Version of Source Code Syntax Highlighting Live Writer Plugin for blogs

In a previous blog post I covered how to create a Windows Live Writer plug-in and then provided the plug-in for download. The plug-in solves the problem of inserting Source Code Syntax formatted code snippets into a hosted blog post from within Live Writer. There are many Plug-ins that can be used with your own hosted WordPress blog but these don’t work with hosted blogs. This plug-in supports only blogs by inserting the relevant ‘ShortCode’ tag around your code that is required for WordPress to syntax highlight your code. As the plug-in has proved popular I’ve taken the time to update it to Version 1.1.

Since developing the first version WordPress have added extra functionality to their SourceCode shortcode. It now supports additional languages and provides more control over how the code snippet appears in your post. Some of the neatest new features include an option to specify specific lines of code within the snippet to highlight, and the ability to control the line number to start line numbering at.

Full Feature List:

autolinks Makes all URLs in your posted code clickable.
collapse If true, the code box will be collapsed when the page loads, requiring the visitor to click to expand it. Good for large code posts.
gutter Hides line numbering on the left side will be hidden.
firstline Use this to change what number the line numbering starts at.
highlight You can list the line numbers you want to be highlighted. For example “4,7,19″.
htmlscript Highlights HTML/XML in your code. This is useful when you are mixing code into HTML, such as PHP inside of HTML.
light A light version of the display, hiding line numbering and the toolbar. This is helpful when posting only one or two lines of code.
padlinenumbers Allows you to control the line number padding. Options are automatic padding, no padding or a specified amount.
toolbar Show or hide the toolbar containing the helpful buttons that appears when you hover over the code.
wraplines Turn wrapping on or off.

Checkout the WordPress support site for more detail on these.

The list of languages selectable within the Plug-in has been increased to include all the new ones now supported by WordPress. The current list is: actionscript3 , bash, coldfusion , cpp , csharp, css, delphi, erlang, fsharp, diff, groovy, javascript, java, javafx, matlab, objc, perl, php, text, powershell, python, ruby, scala, sql, vb, xml.

I’ve also provided a mechanism to modify the list of languages displayed in the Plug-in. This is useful for two reasons. Firstly it enables you to reduce the number languages in the dropdown list down to just the one’s you are likely to use. This can make the Plug-in slightly easier to use. Perhaps more important however is the fact this enables you to modify the list if decide to update their shortcode to support an additional language and you need to utilise this before the next version of my Plug-in is released. Just add the new language name to the list and away you go.

To modify this language list you need to have a text file named SyntaxHighlight_WordPressCom_WLWPlugIn.txt located in the same folder as the Plug-in (usually C:\Program Files\Windows Live\Writer\Plugins). The download Zip file for the V1.1 version of the Plug-in contains this file. Locate it with the plug-in and then it’s there for when you want to modify the list in the future. Interestingly if you don’t want to make use of this feature then it is optional and the text file is NOT required for the Plug-in to work (you’ll just get the full language list by default).

I have changed the display that is inserted into the Editor view when a snippet is inserted. Previously all code text and the shortcode tag was added to the Editor view. To improve readability of the code you’ve inserted a change has been made to only show the code and not the ShortCode tags. This is particularly useful now that the Shortcode tags are potentially longer with the new supported attributes.

A link to the sourcecode tag support page is also now included in the property editor for inserted code snippets.

 WLW_V1.0_FulLScreenCodeEntryFrm WLW_V1.1_FulLScreenProps WLW_V1.1_Props


The “Live Writer Source Code Plugin For” Version 1.1 is available for download here.

Capturing your Camcorder DV Video with Windows Live Movie Maker & Windows 7

I have five years of Mini-DV Camcorder tapes stacked up on my shelve. My plan has always been to transfer the video off onto my PC and then reuse the tapes, but for various reasons this never quite happened, instead the pile just grew bigger and bigger. Not for any longer though as I am refusing to buy anymore tapes and forcing myself to get the video transferred.

Firstly I need to connect the camera and as my camcorder is a Sony its the good old Firewire card and unfortunately Windows 7 (and Vista before it) refuses to recognise it. After some messing about and moving slots (why oh why did Microsoft remove the ability to manually adjust IRQ settings?)  I give up and order a new card (a Belkin 3 port FireWire PCI card) which happily Windows 7 finds and embraces straight away. My Sony then appears in Windows in the list of devices in "My Computer".

Now I have the connectivity I need the software to import the data in. There are numerous options but I already have two installed; Nero and Windows Live Movie Maker. Windows Live Movie Maker replaces Windows Movie Maker but is not included in the Windows 7 installation but instead is part of the free Windows Live Essentials pack for download separately. Nero Vision does a good job but Windows Live Movie Maker provides the option to automatically split the video into multiple files. It seems more natural to me to have a collection of video files instead of a monolithic 60 minute video. Separate files also makes it easy to quickly remove scenes and include extra ones later when adding the video to a DVD.

Importing via Windows Live Movie Maker:

1)  Open Movie Maker and select “Import from device” from the top menu.


2) Select device:


3)  Name the video and pick options:



To create multiple files instead of one monolithic file check the bottom checkbox.

4) Ok the options dialog and click Next, then sit back and wait for the video to stream. It will take as long as the length of video you’re streaming takes to play. If you selected to import the whole tape the video will play for the length of the tape and then will spend around 5 to 10 minutes to splitting up the file.


WARNING: It takes a lot of disk space to import video, with a 60 minute tape creating about 12GB of video files. Make sure that you have plenty of free space before you start to import the video. Also if you have chosen to split the video into multiple files you will need to have double the free space. This is because a single file is created initially (e.g. 12GB) and then the multiple individual files are created before the original is deleted which means that there will be twice the amount of data during this process (e.g. 24GB). If there is not enough disk space to create the individual files then Movie Maker will just inform you that it is unable to split the video into multiple files and you get left with the single file. You would then need to free some more space and then re-import the video again to end up with the desired collection of multiple videos which is a waste of a valuable hour of your life.

What format should I save the Video in?

Now that the video is imported I want to keep it in a digital format but should I store it? Well I wanted to create DVDs from the tapes and so I am using Nero for this purpose as I like the way it creates the DVD menu’s etc. DVD maker included with Windows 7 could alternatively be used for this purpose however. Creating the DVD is not so much for storage but for portability. I like the fact that I can watch my videos on any DVD player but it’s not the ideal way to store the video for the future. Video is compressed down to get it onto a DVD and although the quality is still very good it doesn’t maintain the complete raw format that ‘might’ be useful in the future when converting to new and improved video formats. When looking around for a format to store this 12GB/hour video it occurred to me that although this was a large amount of data it is in fact getting smaller by the day anyway as technology improves. When digital cameras first came out people were looking for ways to compress their images as several MB per photo seemed hard to store. Of course we now take it for granted that a photo is 5MB and hard drives are now sold in the Terabytes meaning it is less of a problem. So I’ve decided to keep my video in it’s raw AVI format for the foreseeable future, and have stored it on my already bulging Windows Home Server.

Syntax Highlighting in hosted blogs and how to create a Windows Live Writer Plug-in

There are various ways of displaying code in a blog entry. Some authors insert images which enable them to ensure that the code is readable and in the required format, however the code can’t then be as easily viewed inside some feed readers, and the text is not searchable or easy to copy/paste. Alternatively an author can just type the text in and use indentation and font styles to distinguish it from the body of the text. By far the best solution however is use a Code Highlighter of some sort that will render the code into a readable format with additional benefits of copy to clipboard, line numbers and colour coding. One popular tool for this job is Syntax Highlighter by Alex Gorbatchev. This uses JavaScript to render the code on the client in a very readable format (see below). It integrates well with the WordPress blog engine and there are several Windows Live Writer Plug-ins for it making it easy to add code snippets to your posts.

Having decided on using Syntax Highlighter for my blog I hit a problem. I’m hosting on and therefore do not have the access required to add it to my site. I found a lot of posts on the web discussing how to integrate it with WordPress but these are for self hosted blogs. Eventually however, to much delight, I found that the developers themselves have already integrated Syntax Highlighter. There is a list of supported languages and details on how to use it here. To activate it you just add a wrap your code inside special tags. Excellent!

Writing a Windows Live Writer Plug-in (Part One)

My next thought though was that I needed to integrate into Windows Live Writer via a plug-in. I couldn’t find a specific plug-in so I fired up MSDN and looked at coding one. All the information you need is on MSDN here

There are two types of plugins. Simple and Smart. As I just needed to add a block of code text surrounded by special tags I figured I would implement the simple type. Simple’s good! Right?

To start with I needed to create a new class library project, reference the Live Writer API (windowslive.writer.api.dll), and add a new class which derived from ‘ContentSource’ and has a ‘InsertableContentSourceAttribute’ attribute.

InsertableContentSourceAttribute("Highlighted Source Code")]
public class MyPlugin : ContentSource

Next override the CreateContent method on the base class. This is the method that gets called when the user clicks to activate our plug-in to insert some content. It returns a DialogResult and has a string parameter passed by-reference called ‘newContent’. This string parameter is how you set the text to be inserted into the blog post.  In the code example shown below I am displaying a form for the user to enter the code block to insert. The form adds the required wrapper text and then the ‘newContent’ string is set to be the whole text content (code plus wrapper text):

public override System.Windows.Forms.DialogResult CreateContent(System.Windows.Forms.IWin32Window dialogOwner, ref string newContent)
    using (codeEntryForm entryform = new codeEntryForm())
        entryform.StartPosition = FormStartPosition.CenterParent;
        DialogResult result = entryform.ShowDialog(dialogOwner); 
        if (result == DialogResult.OK)
            newContent = entryform.GetData();
        return result;

In addition to overriding the CreateContent method the WriterPluginAttribute needs to be set on the class. This basically provides Live Writer with information about your plug-in. For an explanation of the properties see here.

[WriterPlugin (
        " Syntax Highliter Plugin",
        ImagePath = "Images.image.bmp",
        PublisherUrl = "",
        Description = "Inserts code highlight tags around code snippets",

Once done compile it up and copy the assembly to the Plugins folder of your Windows Live writer installation (e.g. C:\Program Files\Windows Live\Writer). When the application starts all the plug-ins in that folder get loaded too. I now had my Syntax Highlighter plug-in, and it worked. I could insert code into my blog post and upload it to the server for WordPress to display using Syntax Highlighter.

Job done then hey? Well not quite. As I had coded this as a SimpleContentSource plug-in once the code snippet had been inserted into the post editor it was treated as plain text (just as if I had written it by hand into the editor). This meant that if I flipped between the Editor and Source windows Live Writer converted my code text to use escape characters. This meant that my code snippet’s quotes and ampersands etc were converted to their friendly alternatives, and would display them without converting them back.

Writing a Windows Live Writer Plug-in (Part Two)

In order to resolve the issue of Live Writer treating my code snippets as regular text I went back to MSDN and found that the SmartContentSource plug-in type provides more control over the HTML that gets sent for publishing. SmartContentSource plug-ins are not treated as regular text and provide more control. Building this type of plug-in is only slightly more work than the less smart plain ContentSource type.

Firstly I needed to change the plug-in class (from above) to override SmartContentSource instead of ContentSource.

[InsertableContentSourceAttribute("Highlighted Source Code")]
public class Plugin : SmartContentSource

Then we override the CreateContent method as we did before. Live Writer creates a ISmartContent object and passes it in for us to update with the content the user creates. Again as before this example has a dialog box being shown to the user for them to key the code snippet but this time the data is set within the ISmartContent properties.

public override System.Windows.Forms.DialogResult CreateContent(IWin32Window dialogOwner, ISmartContent newContent)
    using (CodeEntryForm entryform = new CodeEntryForm())
        entryform.StartPosition = FormStartPosition.CenterParent;
        DialogResult result = entryform.ShowDialog(dialogOwner); 
        if (result == DialogResult.OK)
            newContent.Properties.SetString("OutputHTML", entryform.GetData());
            newContent.Properties.SetString("RawCode", entryform.GetRawCodeSnippet());
            newContent.Properties.SetString("SelectedLanguage", entryform.GetSelectedLanguage());                    
        return result;

N,B: The reason I’m setting the ‘RawCode’ and the ‘SelectedLanguage’ properties as well as the combined total output is for use later when we want to display the dialog to the user again pre-populated.

In order to ensure that the correct text is being passed to the blog engine for publishing we override the GeneratePublishHtml method. The ISmartContent object passed in has the original data set as one of its properties so in this example I just return that.

public override string GeneratePublishHtml(ISmartContent content, IPublishingContext publishingContext)
    return content.Properties["OutputHTML"].ToString();

This gets around the original problem that I experienced with the first ContentSource plug-in. Also SmartContentSource plug-ins benefit from being able to be edited via an editor view. This means that when an inserted code snippet is selected in the Editor in Live Writer we can display our own properties bar on the right hand side. To use this feature we need to add a UserControl to our project and make it derive from SmartContentEditor. We then add relevant controls to it to interact with our Content (i.e. code snippet). In my case I just added a link label control to re-launch the dialog box for the user to modify the code within the currently selected content (code snippet) in the editor. Once complete then override the CreateEditor method and return our own UserControl object as a SmartContentEditor object .

public override SmartContentEditor CreateEditor(ISmartContentEditorSite editorSite)
    return new MySmartContentEditor();

An important point is that only one instance of the plug-in is used in Live Writer for all instances of content being inserted. For example you may add multiple code snippets into one blog post but only one instance of your plug-in will be created and reused, therefore you cannot store any state information specific to an individual content items (i.e. Code snippets) within the plug-in. That’s why the data is always passed in to these methods we have been overriding.

Compile it up and copy the assembly to the PlugIns folder of your Windows Live writer installation (e.g. C:\Program Files\Windows Live\Writer\Plugins) to test. This time the content added using SmartContentSource is treated as special and is not converted as you flip between the Editor and Source views.

To extend the plug-in further its possible to update the ‘WriterPlugin’ attribute property ‘HasEditableOptions’ to true and override the ‘EditOptions’ method to display an options dialog to the user. This means that you can let the user modify settings for your plug-in. 

As you can see the plug-in model for Windows Live Writer is very simple and productive. It is surprisingly easy to quickly produce useful plug-ins.

If you want to make use of this plug-in for making it easier to add highlighted code to your blog then feel free to download it here.

Accessing ‘Live Mesh’ From Your Non-Windows Mobile

imageMicrosoft ‘Live Mesh’ provides the ability to synchronise your data across all your devices via ‘the cloud’. This means you can access your files no matter which PC you’re using, and also extends to Windows Mobile devices. But what if you want access to these files from a non-Windows mobile such as a Nokia Symbian Smartphone. Whilst Microsoft does not provide a Symbian client application (yet!) it is possible to access your Live Mesh folders via your phone’s browser using the Live Mesh mobile web site:

This won’t synchronise your files to the device but it does allow you to upload and download files to/from your mesh folders using a mobile friendly web interface. I find this a very useful way to access my files on the move from my Nokia E71.

Live Mesh : Specify Folder Locations

Windows Live Mesh is a nifty tool for sharing data across various devices. One problem with it though is that by default new Mesh Folders are added to the Desktop of all the devices in your mesh. There is a way to prevent this though.

Creating a new Mesh folder and setting it to synchronise with all your other devices will mean that it appears on the desktop of those machines. The way to avoid this is by ensuring that when you set up a new folder (from either the Live Desktop or directly on any of the devices) make sure that the ‘Synchronise Files’ setting is set to ‘Never with this device’ for all devices (as below):


From each individual device you will now be able to see the new folder in the Live Mesh ‘Manage Folders’ view. From there select the new folder, right click and select ‘Change Synch Settings’  which shows the Change Synchronization dialog (as above) but the Name and Location fields are now also enabled allowing you to change the location of the file on the current device. Specify a folder location and then change the ‘Synchronise Files’ setting to ‘When files are added or modified’ for the local machine (as below). The files will now Synchronise as normal but to the chosen target folder and not your desktop.


Repeat this process for the each device in your Mesh.