OpenLiveWriter

Congratulations to the team who worked so hard to get OpenLiveWriter completed. Thanks must go to Scott Hanselman for championing this for so long.

See the announcement at http://www.dotnetfoundation.org/blog/open-live-writer.

Advertisements

WPF: Re-creating VS2012 window glow

WPF: Re-creating VS2012 window glow

WPF is such a powerful technology that I’m reminded of the Perl mantra, there’s more than one way to do it. So rather than just giving you some code, this post is also about explaining why I’ve used several WPF techniques so that you can find some reuse for them too.

Window Glow

It seems such an easy thing to do at first, just to add a bit of outer glow chrome around the window and highlight your window amongst the stark simplicity of modern windows. The most naive implementation of this would be to simply building up some glow around a single pixel of colour. In fact this (very bad) piece of code  below does exactly that, just by layering several borders;

<Window x:Class="VS2012OuterGlowArticle.MainWindow" 
xmlns=http://schemas.microsoft.com/winfx/2006/xaml/presentation 
xmlns:x=http://schemas.microsoft.com/winfx/2006/xaml 
Title="MainWindow" 
Height="350" Width="525"> 
 <Border Padding="1" CornerRadius="8">
 <Border.Background> 
 <SolidColorBrush Color="DarkOrange" Opacity="0.06"/> 
 </Border.Background> 
 <Border Padding="1" CornerRadius="8"> 
 <Border.Background>
  <SolidColorBrush Color="DarkOrange" Opacity="0.06"/> 
 </Border.Background> 
 <Border Padding="1" CornerRadius="8"> 
 <Border.Background>
 <SolidColorBrush Color="DarkOrange" Opacity="0.06"/>
 </Border.Background> 
 <Border Padding="1" CornerRadius="8">
 <Border.Background> 
 <SolidColorBrush Color="DarkOrange" Opacity="0.06"/>
 </Border.Background>
 <Border Padding="1">
 <Border.Background>
 <SolidColorBrush Color="DarkOrange" Opacity="0.06"/>
 </Border.Background>
 <Border BorderBrush="DarkOrange" BorderThickness="1" Background="White"/>
 </Border>
 </Border>
 </Border>
 </Border>
 </Border>
 </Window> 

And looks like thisglow2

Obviously there are a few flaws with this, but it does highlight exactly why I think WPF is a great advance over WinFoms. The primitives that we can build from in WPF are very flexible and can be used to create fabulous effects when we don’t know another way to do it.

Effects

But WPF also provides some great built in effects and one of these makes our life much simpler. We can use the DropShadowEffect without any ShadowDepth to give us an outer glow with far less code.

<Window x:Class="VS2012OuterGlowArticle.MainWindow" 
xmlns=http://schemas.microsoft.com/winfx/2006/xaml/presentation 
xmlns:x=http://schemas.microsoft.com/winfx/2006/xaml 
Title="MainWindow" 
Height="100" Width="200" >
 <Border BorderBrush="DarkOrange" BorderThickness="1" Background="White" Margin="5">
 <Border.Effect>
 <DropShadowEffect ShadowDepth="0" BlurRadius="5" Color="DarkOrange"/>
 </Border.Effect>
 </Border>
</Window> 

 

glow3

Outside not inside

Now you might be wondering why I haven’t tried to put the outer glow on the outside of the window so far, well there is a very simple reason, windows even under the post Vista world, still have hard region limits. If we add the effect to the window it attempts to draw outside of the region, and simply gets clipped.

<Window x:Class="VS2012OuterGlowArticle.MainWindow" 
 xmlns=http://schemas.microsoft.com/winfx/2006/xaml/presentation 
 xmlns:x=http://schemas.microsoft.com/winfx/2006/xaml 
 Title="MainWindow" 
 Height="350" Width="525"> 
 <Window.Effect> <!-- This doesn't work, shame--> 
 <DropShadowEffect ShadowDepth="0" BlurRadius="5" Color="DarkOrange"/>
 </Window.Effect>
 <Grid>
 </Grid>
</Window> 

Hmmm so maybe that’s why…

So at this point, we can see that we are going to need to provide the transparency inside the region of our window. Maybe that’s why the VS2012 window is drawn with a completely custom chrome?

If we just try setting our Window.Background=”Transparent” nothing happens again, but that is primarily because we haven’t turned on Window.AllowsTransparency=”true” as well, and unfortunately running the code at this point results in an error telling us the only acceptable WindowStyle is WindowStyle=”None”.

 

 

<Window x:Class="VS2012OuterGlowArticle.MainWindow" 
 xmlns=http://schemas.microsoft.com/winfx/2006/xaml/presentation 
 xmlns:x=http://schemas.microsoft.com/winfx/2006/xaml 
 Title="MainWindow" 
 Height="100" Width="200" 
 AllowsTransparency="True" WindowStyle="None" Background="Transparent"> 
 <Border BorderBrush="DarkOrange" BorderThickness="1" Background="White" Margin="5">
 <Border.Effect>
 <DropShadowEffect ShadowDepth="0" BlurRadius="5" Color="DarkOrange"/>
 </Border.Effect>
 </Border>
</Window> 

 

glow4

As you can see we now have our glow but lack everything else. However I think this once again helps us as it frees us from the constraints of the OS look and lets us do whatever else we want to. You can get most of your functionality back by integrating the Microsoft.Windows.Shell library. This is a superset of System.Windows.Shell and includes handling extending glass which we can subvert to provide such things as window drag and resize borders. Normally I have all of this in a style, and so the relevant part looks like this.

<Setter Property="shell:WindowChrome.WindowChrome"> 
 <Setter.Value>
 <shell:WindowChrome 
 ResizeBorderThickness="4" CaptionHeight="24" 
 CornerRadius="0" GlassFrameThickness="0"/>
 </Setter.Value>
</Setter>

For now, however I’m going to simply add a close button

<Grid>
 <Button HorizontalAlignment="Right" VerticalAlignment="Top"
 Background="DarkOrange" Foreground ="White" BorderThickness="0"
 Click="Window_Close">
 X
 </Button>
</Grid> 

glow5

 

Maximised windows

Even though we haven’t provide the UI to allow the user to maximise the window with the mouse, you can still use the Windows7 shortcuts, Windows+Up/Left/Right, and there is a problem. Remember that margin that we needed around our border to allow us the room for our gradient, well its still there.

If you maximise your window you also are still left with the single pixel Border all round your window, but we can quite easily deal with this. I first used a custom converter on a Binding from WindowState that produces a zero Thickness for the border when WindowState=”Maximised”.

But if you snap your window to the left or right with Windows+Left/Right you can also see it quite plainly, and this time the window hasn’t changed state, just size.

glow6

Well, I suppose I could just check on when the window size changes and just turn off the relevant borders, but unfortunately there doesn’t seem to be an easy way to find the size of the working area (ie. the bit without the the taskbar) of the screen in WPF. You can get it for the Primary screen, but not the current. Which is fine as long as you are sure nobody is ever going to run your application on multiple monitors.

In fact, some investigation of this lead me to http://stackoverflow.com/questions/1927540/how-to-get-the-size-of-the-current-screen-in-wpf and an answer by Nils http://stackoverflow.com/users/180156/nils where he wraps the WinForms assembly in a nice class called WpfScreen, and this allows us to set both the border and the BorderThickness containing the glow.

This allows me to simply determine the border and margin (where the glow appears) to be calculated like this;

if (window.WindowState == WindowState.Maximized)
{
 //No point in glowing when you cant see the glow 
 border.Margin = new Thickness(0); 
 border.BorderThickness = new Thickness(0); 
 return; 
} 
// Snapped windows are a little more awkward to detect 
// todo: Need to get current screen height not primary 
var workingArea = WpfScreen.GetScreenFrom(window).WorkingArea; 
if (window.Top == workingArea.Top && window.Height == workingArea.Height) 
{ 
 border.Margin = new Thickness( 
 window.Left == workingArea.Left ? 0 : GLOW_BORDER_MARGIN, 
 0, 
 window.Left + window.Width == workingArea.Right ? 0 : GLOW_BORDER_MARGIN,
 0); 
 border.BorderThickness = new Thickness( 
 window.Left == workingArea.Left ? 0 : 1, 
 0, 
 window.Left + window.Width == workingArea.Right ? 0 : 1, 
 0); 
 return; 
} 
border.Margin = new Thickness(GLOW_BORDER_MARGIN); 
border.BorderThickness = new Thickness(1);

And as they say, here’s one I made earlier; notice how the top glow is missing since its snapped to the left hand side.

glow7

Reusability

Now at this point you have enough to go off and replicate this effect. Just add a Window_SizeChanged handler with the above snippet, add a border with it’s effect into the window xaml, and include Microsoft.Windows.Shell assembly for window resizing and repositioning and your done. However applications often need more than one window and there’s always the next application too, so we want to avoid copying and pasting the code around.

Normally we would just use a derived class to handle this, but the problem here is that the user may already be using a UI framework that adds some functionality, possibly even a corporate standard one that they can’t change and is now just looking just to change the look and feel. We could use a Mixin class that allows us to include the additional functionality, but then the user would still be need to add initialisation code to the code-behind in order to trigger it, which isn’t really look-less really.

Fortunately WPF provides the means with attached properties. We can define an attached property so that when we set some value in the xaml, then this triggers a registration process. Since we need to identify which border we are going to be switching on and off, then I’ve chosen to make this the value I need to set in my property, i.e.

<Border BorderThickness="1" BorderBrush="DarkOrange" WinChrome:Modern.GlowBorder="True">
 ...
</Border>

And finally

Since the ultimate form of re-usability these days seems to come from open-sourcing ones code, I’m dropping all of this into winchrome.codeplex.com.

Bad developers plagiarise, Good developers steal

I’ve been reading the conversation that Scott Hanselman kicked off about Good developers vs Google developers and I have to say that my own feelings are pretty much summed up by those of Rick Strahl.

Except for one point.

Like many of these issues there is no black and white, but there is a lot of grey. Rick et al., have pointed out the advantages of using a reference library, such as the meta-library provided to us by the internet, but my point is not only that its desirable, but actually necessary to be a good developer.
Without the reference to see many examples, how can one determine what makes code better or us?
Without somebody proposing good design, how do we identify bad?

In short how so we avoid being an isolationist set of teams, with many local maxims, instead of a cohesive profession where we can all benefit.

And with that though in mind I’m really glad I went to tonight’s LDNUG.

Using SpecFlow isn’t necessarily a good practice

There’s been a batch of questions on StackOverflow recently on the SpecFlow questions feed that follow a similar pattern.

All these questions have one thing in common, they are definitely not using BDD. I’m not sure what they are doing, in one case, SpecFlow is used to set up a test run and gather performance data, but there is never a comparison or an assertion. I’d struggle to even call it testing as the test must be performed manually by looking at the data.

But all this is a micro level abstraction of a bigger problem, which it looks like Liz Keogh is feeling at the moment. Her latest post Behaviour Driven Development – Shallow and Deep definitely indicates that this phenomenon is not just isolated to technical individuals trying out new ways of doing things and getting it wrong, but that those habits seem to then pass on to the organisations that they work for.

I love the way that Liz talks about this problem in the context of having a conversation with somebody else. In fact I might just go for a little chat myself.  

The Deployment maturity model

A long time ago I came across the Personal Threading Maturity Model and I still keep referring back to it as a measure of how much further I have to go. Today however, it struck me that I probably could do with some other yardsticks to show how far off nirvana some of things I’m doing really are. With that in mind I present the Deployment Maturity Model, my take on how things often work, how I can see them working if I really push, and how things work in organisations that get it.

Unaware

Uses manual deployment strategy such as xcopy/ad-hoc SQL to change what they want where they want. Usually the production deployment is a bespoke process that is never practiced in advance in other environments. This unfortunately makes them time consuming and error prone.

Authorisation/Sign off and security are totally incidental. Sometimes they are considered, but only the personal high standards of good developer practices prevents them from being abused.

Post-release testing is achieved by manually using the production system and confirming the new functionality. Rollback is achieved by taking a backup copy at the start of the release, and/or providing SQL rollback scripts.

Casual

Introduction of packages, such as MSIs, that ensures that some components of a deployment can be upgraded as a single unit, such as application + shared dlls. However for multi-tier applications the other tiers are commonly tightly coupled with these changes, e.g. database updates, so they require downtime and synchronization between tiers. Packages can be deployed in Dev, test and production, but often require additional manual interaction such as switching back end tier or service connections and changes to database.

Authorisation to release is always considered at this level with external RFC/Change management systems being the norm, but security/the ability to release to production is still often in the hands of the developer. Post-release testing is still manual. Rollback can now be achieved in part by redeploying the previous version packages, although a common problem is that ad-hoc changes have been made to configuration files, which need to be re-applied or manually backed up before the release occurs.

Rigid

Begin use of deployment management software. Software ensures that all components of a release are released at the same time. Releases happen much faster and more reliably as process is automated and consistent process is used across development, test and production environments. Configuration should be a product of the deployment process, so values are injected during release to associate tiers/services together. All ad-hoc production changes should be banned.

Security is now locked down, with no write-access to production for developers being the norm. Tools however are still not joined up between tracking the changes included e.g. Jira, gathering authorisation e.g. Remedy and performing the release e.g. OctopusDeploy. Down time is reduced as releases can be staggered within tiers. Strategies such as load balancing used to keep application constantly available while individual services are rotated out of service for upgrade.

Rollback is by re-releasing the previous version. Testing should also change to use automated test packs that can be run as soon as new environments are available primarily in test environments, but also with shakedown packs that can be run in production post release.

Flexible

Additional opportunities to utilise infrastructure are employed due to the ease at which deployments can now be achieved. Opportunities to create multiple instances of a tier or service are used, so that current and previous versions are always available, e.g. direct certain clients to new front end, or point certain servers to new back end services.

Applications and services are written to support switch on/off new features for subsets of usage e.g. per client, or redirect to alternate service instances, i.e. switch on of new version is runtime application setting change, not a deployment.

Deployment tools now starts to link up, and orchestration of how/when to perform the release becoming an additional feature. Some systems may even allow you to define the future state of your environment, and let the software work out which pieces need releasing.

Release testing can now be performed in production with pilot subsets in advance of migrating true production processing on to it, and releases then staggered by moving subsets over at a time. Rollback is now trivial by using instance of service that is still on previous version and which remains live until later decommissioning.

Optimising

Support for change of services and tiers embraced across entire architecture. Infrastructure fully utilised to support multiple versions of service instances and ensure balanced load. Since release process is proven and trivial, continuous deployment should be used to automatically deploy every candidate release that meets quality gates to production so that change is incremental. Load-balancing used heavily so that release downtime is zero, and impact from release, e.g. load performance, is negligible.

Deployment tools need to be completely joined up or face irrelevance, e.g Authorisation to release simply becomes one of the quality gates leading to automated release, and with a good testing framework, could be automatically given if the criteria for acceptance can be defined and verified electronically.

Rollback happens automatically should issues be detected. Roll forwards is as trivial as it can be.

Some links

If you read only one link, start with this one http://timothyfitz.com/2009/02/10/continuous-deployment-at-imvu-doing-the-impossible-fifty-times-a-day/

Using NuGet 2.5 to deliver unmanaged dlls

A little while ago I looked at a way to deliver unmamaged dlls via NuGet 2.0. Well now there’s NuGet 2.5 and they’ve only gone and fixed all the problems.

The two problems unsolved from before were

  • How to package the set of dlls
  • How to inject our new build target into msbuild so that it copies over our dlls

Introducing native dlls

The first new feature in 2.5 is Supporting Native projects. Its quite simple, underneath you lib folder you can now add a new type native. The first thing you will notice when you try this out, is that you can’t just ship a set of lib\native files, you need something else.

Could not install package ‘MyPackage 1.0.1’. You are trying to install this package into a project that targets ‘.NETFramework,Version=v4.5’, but the package does not contain any assembly references or content files that are compatible with that framework. For more information, contact the package author.

You can simply add a content folder with a readMe.txt or similar, to get around this issue.

Installing a package built like this reveals that although the files end up copied into the packages\myPackage.vx.x.x\lib\native folder, nothing happens to them when you run a build.

Automatically including .props and .targets

The 2nd new feature is Automatic import of msbuild targets and props files. In short if you add a .props file in the Build folder of your package, it gets added to the start your .csproj, and if you add a .targets it gets added to the end. This is where I refer back to my earlier post and we can now copy over that little script.

 

<?xml version="1.0" encoding="utf-8"?> 
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> 
  <Target Name="AfterBuild"> 
    <ItemGroup> 
      <MyPackageSourceFiles Include="$(MSBuildProjectDirectory)\..\Packages\FakePackage\*.*"/> 
    </ItemGroup> 
    <Copy SourceFiles="@(MyPackageSourceFiles)" 
DestinationFolder="$(OutputPath)" > 
    </Copy> 
  </Target> 
</Project>