Excel & Neo4j? Let’s code that! (VSTO edition)

So you have a new Graph Database, it’s looking snazzy and graphy and all that, but, well – you really want to see it in a tabular format, ‘cos you’ve got this Excel program hanging about, and well – who doesn’t love a bit of tabular data?

Obviously there are loads of reasons why you might want that data – maybe to do a swanky graph, perhaps to pass over to the boss. You can also get that data into Excel in a few ways –

  • Open up from the Web – you can try opening up the REST endpoint in Excel directly – (I say try because quite frankly – it’s not looking like a good option)
  • Create an application to export to CSV – this is easy – writing a CSV/TSV/#SV is a doddle (in any language) but does mean you have to give it to people to run, and that might give more headaches – however it’s an option!
  • Create an Excel Addin that runs within Excel – slightly more complicated as you need to interact with Excel directly – but does have the benefit that maybe you can use it to send data back to the db as well..

As you can imagine, this is about doing the third option – to be honest, I would only ever pick options 2 or 3, and if I’m super honest – I would normally go for option 2 – as it’s the simplest. Option 3 however has some benefits I’d like to explore.

If you want to look at the project – you can find it at: https://github.com/DotNet4Neo4j/Neo4jDriverExcelAddin

I’ll be using the official driver (Neo4j.Driver) and VSTO addins, with VS 2017.

Onwards!

Sidenote

As I was writing this, I was going to do my usual – step-by-step approach, so went to take a screenshot and noticed this:

image

So we’re going to do a quick overview of the VSTO version, then the next post will tuck into the Excel Web version which looks snazzier – but I don’t have an example as of yet…

Onwards again!

Sidenote 2: Sidenote Harder

As the code is on github I’m not going to show everything, merely the important stuff, as you can get all the code and check it out for yourself!

So – pick the new VSTO addin option:

image

And create your project. You’ll end up with something like this:

image

OK, so an addin needs a few things –

  1. A button on the ribbon
  2. A form (yes, WinForm) to get our input (cypher)
  3. The code that executes stuff

The Form

That’s right. Form. Actually – UserControl, but still WinForms (Hello 2000), let’s add our interface to the project, right click and ‘Add New Item’:

image

For those who’ve not had the pleasure before, the key thing to learn is how the Anchors work to prevent your form doing weird stuff when it’s resized.

Add a textbox to the control:

image

Single line eh? That’s not very useful – let’s MULTI-LINE!

Right–click on the box and select properties and that properties window you never use pops up, ready to be used! Change the name to something useful – or leave it  – it’s up to you – the key settings are Anchor and Multiline. Multline should be true, Anchor should then be all the anchors:

image

If you resize your whole control now, you should see that your textbox will expand and contract with it – good times!

Drag a button onto that form and place it to the bottom right of your textbox, and now we need to set the anchors again, but this time to Bottom, Right so it will move with resizing correctly – also we should probably change the Text to something more meaningful than button1 – again – don’t let me preach UX to you! Play around, make it bigger, change the colour, go WILD.

Once your button dreams have been realised – double click on the button to be taken to the code behind.First we’ll add some custom EventArgs:

internal class ExecuteCypherQueryArgs : EventArgs
{
     public string Cypher { get; set; }
}

and then a custom EventHandler:

internal EventHandler<ExecuteCypherQueryArgs> ExecuteCypher;

Then we call that event when the button is pressed, so the UserControl code looks like:

public partial class ExecuteQuery : UserControl
{
    internal EventHandler<ExecuteCypherQueryArgs> ExecuteCypher;

    public ExecuteQuery()
    {
        InitializeComponent();
    }

    private void _btnExecute_Click(object sender, EventArgs e)
    {
        if (string.IsNullOrWhiteSpace(_txtCypher.Text))
            return;

        ExecuteCypher?.Invoke(this, new ExecuteCypherQueryArgs { Cypher = _txtCypher.Text });
    }
}

The Ribbon

OK, we now have a form, but no way to see said form, so we need a Ribbon. Let’s add a new  Ribbon (XML) to our project

image

Open up the new .xml file and add the following to the &lt;group&gt; elements:

<button id="btnShowHide" label="Show/Hide" onAction="OnShowHideButton"/>

Now open the .cs file that has the same name as your .xml and add the following:

internal event EventHandler ShowHide;

public void OnShowHideButton(Office.IRibbonControl control)
{
    ShowHide?.Invoke(this, null);
}

Basically, we raise an event when the button is pressed. But what is listening for this most epic of notifications??? That’s right.. it’s:

ThisAddin.cs

The unfortunate part about going from here on in is that this is largely plumbing… ugh! The code around how to show/hide a form I’ll skip over – it’s all in the GitHub repo and you can read it easily enough.

There are a couple of bits of interest – one is the ThisAddin_Startup method, in which we create our Driver instance:

private void ThisAddIn_Startup(object sender, EventArgs e)
{
     _driver = GraphDatabase.Driver(new Uri("bolt://localhost"), AuthTokens.Basic("neo4j", "neo"));
}

To improve this, you’d want to get the URL and login details from the user somehow, perhaps a settings form – but I’ll leave that to you! – The important bit is that we store the IDriver instance in the addin. We only want one instance of a Driver per Excel, so this is fine.

The other interesting method is the ExecuteCypher method – (which is hooked up to in the InitializePane method) – This takes the results of our query and puts it into Excel:

private void ExecuteCypher(object sender, ExecuteCypherQueryArgs e)
{
    var worksheet = ((Worksheet) Application.ActiveSheet);

    using (var session = _driver.Session())
    {
        var result = session.Run(e.Cypher);
        int row = 1;
        
        foreach (var record in result)
        {
            var range = worksheet.Range[$"A{row++}"]; //TODO: Hard coded range
            range.Value2 = record["UserId"].As<string>(); //TODO: Hard coded 'UserId' here.
        }
     }
}

Again – HardCoded ranges and ‘Columns’ (UserId) – you’ll want to change these to make sense for your queries, or even better, just make them super generic.

Summing Up

So now we’re at this stage, we have an Excel addin using VSTO that can call Cypher and display the results, there are things we probably want to add – firstly – remove all the hard coded stuff. But what about being able to ‘update’ results based on your query?? That’d be cool – and maybe something we’ll look at in the next addin based post (on Web addins).

Managed Application Framework – Part 2 – Basic Versioning!

Soooo… A post from a while ago covered the basic Managed Addin Framework (MAF from here-in) and how to set up a basic addin with host and pipeline.

One of the big problems of an Addin situation is if we change the contract between our Addins and our host. This can happen for a number of reasons – added functionality, removed functionality, the dreaded security etc… So, we change our contract and OH NOES! break all the AddIns we’ve carefully nurtured to maturity.

Luckily the guys who developed the MAF have come up with a solution to this, and it all lies with the pipeline………

Previously we had the IHelloMAF contract:

[AddInContract]
public interface IHelloMAF : IContract
{
string HelloMAF();
}

Obviously this gives us a limited set of functionality, so lets add a little bit more:

[AddInContract]
public interface IHelloMAF : IContract
{
string Hello(string name);
}

This will give us the power to accept inputs! Of course, this is just the contract, the detail is in the actual implementation itself.

If I simply update the contract and rebuild the pipeline, then my previously created AddIn will stuff up as it implements the old contract, I would have to change the AddIn to implement the new version, but I don’t or maybe can’t do that.

What does that mean for the development? Basically, we need to create another adapter, one to convert version 1 addins to work as a version 2 addin. To do this, we use the Pipeline builder, it saves a lot of time and effort in the long run. We need to be able to tell the Pipeline builder that, actually, generate a new AddInView, not overwrite the existing one. To do this, we reference in the PipelineHints dll (this is in the location you installed the PipeLine builder – in my case: C:\Program Files\Microsoft\Visual Studio Pipeline Builder\PipelineHints.dll).

Once we have the hints dll referenced we can go to our Contract file and put the following in:

[assembly: PipelineHints.SegmentAssemblyName(PipelineHints.PipelineSegment.AddInView, “AddInView2”)]

** Put this ABOVE the namespace declaration (if you have one)!! **

What this effectively does is force the Pipeline builder to create the AddInView segment for this contract, but name it ‘AddInView2’ rather than it’s default ‘AddInView’.

If we now run the Pipeline builder, we will generate some new projects, including ‘AddInView2’, note – the ‘AddInView’ project is still there, aces!

After this we need to update the host to cope with the new contract (** IF we changed the contract name, if we didn’t then no updates required **), should be pretty simple.

We can then create a new AddIn, based off of the new contract, and once we’ve done that, run the host and load up our new AddIn. All should be working!

But the version 1 addin isn’t showing – this is expected at the moment. The pipeline builder has only created a pipeline for the new style of Addin. What we need to develop is a v1 addin to v2 addin adapter. The easiest thing to do is copy from the AddInSideAdapters project.

We create a new Class Library project, calling it something like AddInV1ToV2Adapter, which gives us a good start point.
Add in references to:
System.AddIn
System.AddIn.Contract
AddInView (the version 1 addin!)
Contracts
(Again, Copy to local = FALSE!!)

Then opening the AddInSideAdapters project, copy the IXXXViewToContractAddIn.cs contents and paste them into your ‘Class1.cs’ file. Now we just need to edit the code to do our translation, so.. first things first, rename the class, doesn’t really matter what it’s called!

You should find the only thing you really need to change is the implementation of the methods, so in our example, we’d have:

public virtual string Hello(string msg)
{
return _view.HelloWorld();
}

Rebuild the entire solution and run the host… Now our host detects 2 AddIns, which is perfect!

I would attach the code to this post, but my blog host doesn’t allow attachments at the moment, I am in the process of looking into this!
If you want it, please email me: cs7kardon [-=At=-] xc7lave . c7o . uk (remove the ‘7’s and compress!)

Pulsy Button

After much umming and ahhing, and developing several versions of BrokeyButton I have the first cut of the PulsyButton.

What is PulsyButton? Well, it’s a button – that pulses. By pulsing I mean that it ‘pulses’ between the Background colour and a ‘PulseColour’ (that you set!).

Pulsy Button

Easy usage:
<PulsyButton Content="Hello" BackgroundColor="LightGray" PulseColor="Red" IsPulsing="True"/>

Obviously if IsPulsing is set to false then the button won’t pulse.
As it’s just based off the ‘Button’ base class, you can literally insert it wherever you have a Button, and all your styles etc will work fine.

I have plans to add more properties, and will over time:
* PulseTime — A TimeSpan for the pulse.
* PauseTime — A TimeSpan to pause the pulse for, i.e. pulse-paaaaauuuuusssseeeee-pulse etc

Also plans to fix some problems:
* Use StoryBoard and set the Background property directly
* Get rid of BackgroundColor property, so only Background is needed

Erm, can’t think of others at the moment.


Bit more detail -> What have I done?

Well, I had a lot of trouble getting a StoryBoard to work programmatically, I don’t know why, and I will perservere. But in the mean time, I’ve resorted to just a simple ColorAnimation.

How have I used a ColorAnimation with a Background brush?

Well, first I created a DependencyProperty:

public static readonly DependencyProperty BackgroundColorProperty
= DependencyProperty.Register( "BackgroundColor", typeof( Color ), typeof( PulsyButton ),
new UIPropertyMetadata( BackgroundColorChanged ) );

private static void BackgroundColorChanged( DependencyObject d, DependencyPropertyChangedEventArgs e )
{
PulsyButton pb = (PulsyButton) d;
pb.Background = new SolidColorBrush( (Color) e.NewValue );
}

This was my ahem workaround to the setting of the Background property directly, as the ColorAnimation will only animate Color properties (i.e. target the SolidColorBrush.Color property for the brush). By the by, it was the targeting of that property that caused me much hassle.

Anyhews, once we’re there, we should also have a PulseColor property (yes I know colour should have a ‘u’ in it, but I’ve gone all americanized :))

public static readonly DependencyProperty PulseColorProperty
= DependencyProperty.Register( "PulseColor", typeof( Color ), typeof( PulsyButton ),
new UIPropertyMetadata( PulseColorChanged ) );

public Color PulseColor { get { return (Color) GetValue( PulseColorProperty ); } set { SetValue( PulseColorProperty, value ); } }

private static void PulseColorChanged( DependencyObject d, DependencyPropertyChangedEventArgs e )
{
PulsyButton pb = (PulsyButton) d;
pb._pulseAnimation.To = (Color) e.NewValue;
}

Here I’ve included the PulseColor property, rest assured there is a BackgroundColor property as well. So, now we have the two colours to animate between, Background -> Pulse -> Background… We just need to create the animation.

private readonly ColorAnimation _pulseAnimation = new ColorAnimation();

There’s no need to recreate it, so it’s a readonly member. But when do I set this bad boy up? Not the constructor – nooooo, the colour properties won’t have been set up at that point, so I’ve gone for a ‘Loaded’ event consumer.

public PulsyButton()
{
Loaded += PulsyButton_Loaded;
}

private void PulsyButton_Loaded( object sender, RoutedEventArgs e )
{
_pulseAnimation.From = BackgroundColor;
_pulseAnimation.To = PulseColor;
_pulseAnimation.Duration = new Duration( TimeSpan.FromSeconds( 1 ) );
_pulseAnimation.AutoReverse = true;
_pulseAnimation.RepeatBehavior = RepeatBehavior.Forever;


this.BeginAnimation( BackgroundColorProperty, _pulseAnimation );
}

The animation will now begin, and the pulsy fun is nearly there!
But wait… what about turning pulse on/off?

All that is done in the IsPulsingChanged property:

private static void IsPulsingChanged( DependencyObject d, DependencyPropertyChangedEventArgs e )
{
bool isPulsing = (bool) e.NewValue;
PulsyButton pb = (PulsyButton) d;
if( !isPulsing )
{
pb._pulseAnimation.RepeatBehavior = new RepeatBehavior( 0 );
pb.BeginAnimation( BackgroundColorProperty, pb._pulseAnimation );
}
else
{
pb._pulseAnimation.RepeatBehavior = RepeatBehavior.Forever;
pb.BeginAnimation( BackgroundColorProperty, pb._pulseAnimation );
}
}

Now, I’m not 100% sure this is the correct way to do this, in fact I’m certain it’s not. However, it does work, which at the moment is what matters.

So there you have it, a button that pulses.

——————=====================———————–

Can’t attach the code to the post, so gonna have to past it here, sorry!!

using System;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Media;
using System.Windows.Media.Animation;

public class PulsyButton : Button
{
private readonly ColorAnimation _pulseAnimation = new ColorAnimation();

public readonly DependencyProperty IsPulsingProperty
= DependencyProperty.Register( “IsPulsing”, typeof( bool ), typeof( PulsyButton ),
new UIPropertyMetadata( IsPulsingChanged ) );

public bool IsPulsing
{
get { return (bool) GetValue( IsPulsingProperty ); }
set { SetValue( IsPulsingProperty, value ); }
}

private static void IsPulsingChanged( DependencyObject d, DependencyPropertyChangedEventArgs e )
{
bool isPulsing = (bool) e.NewValue;
PulsyButton pb = (PulsyButton) d;
if( !isPulsing )
{
pb._pulseAnimation.RepeatBehavior = new RepeatBehavior( 0 );
pb.BeginAnimation( BackgroundColorProperty, pb._pulseAnimation );
}
else
{
pb._pulseAnimation.RepeatBehavior = RepeatBehavior.Forever;
pb.BeginAnimation( BackgroundColorProperty, pb._pulseAnimation );
}
}

public static readonly DependencyProperty PulseColorProperty
= DependencyProperty.Register( “PulseColor”, typeof( Color ), typeof( PulsyButton ),
new UIPropertyMetadata( PulseColorChanged ) );

public Color PulseColor { get { return (Color) GetValue( PulseColorProperty ); } set { SetValue( PulseColorProperty, value ); } }

private static void PulseColorChanged( DependencyObject d, DependencyPropertyChangedEventArgs e )
{
PulsyButton pb = (PulsyButton) d;
pb._pulseAnimation.To = (Color) e.NewValue;
}

public Color BackgroundColor
{
get { return (Color) GetValue( BackgroundColorProperty ); }
set { SetValue( BackgroundColorProperty, value ); }
}

public static readonly DependencyProperty BackgroundColorProperty
= DependencyProperty.Register( “BackgroundColor”, typeof ( Color ), typeof ( PulsyButton ),
new UIPropertyMetadata( BackgroundColorChanged ) );

private static void BackgroundColorChanged( DependencyObject d, DependencyPropertyChangedEventArgs e )
{
PulsyButton pb = (PulsyButton) d;
pb.Background = new SolidColorBrush( (Color) e.NewValue );
}

public PulsyButton()
{
Loaded += PulsyButton_Loaded;
}

private void PulsyButton_Loaded( object sender, RoutedEventArgs e )
{
_pulseAnimation.From = BackgroundColor;
_pulseAnimation.To = PulseColor;
_pulseAnimation.Duration = new Duration( TimeSpan.FromSeconds( 1 ) );
_pulseAnimation.AutoReverse = true;
_pulseAnimation.RepeatBehavior = RepeatBehavior.Forever;

this.BeginAnimation( BackgroundColorProperty, _pulseAnimation );
}
}

Extensionising Wpf (or Chris’ fun with Extension methods and Wpf)

To be honest, it’s not really trouble using, or indeed writing extension methods, I don’t really have any troubles writing them, it’s more what I wanted to do with them that has bugged me.

As everyone who gets into writing WinForms / WPF apps knows, there will come a point where you will need to partition the work you’re doing to another thread. The usual reasons (so you can do other things, so the UI doesn’t lose it’s interactivity etc) apply.

Once you’ve entered this world you may even want to update the UI from within the thread – maybe it’s just a simple thing like enabling a button, changing the text on a label (etc). It’s quite a common thing to do and as such you can find shed loads of blogs, articles on the whys and wherefores of achieving those goals. I’ve been a WinForms developer for oooh, 4 years now, with the last year being a crossover of WPF / WinForms development. As a consequence I’ve done this quite a lot, and tend to find I have the same methods littering my code for achieving these goals:

private delegate void UpdateControlVisibilityDelegate(Control control, Visibility visibility);
private void UpdateControlVisibility(Control control, Visibility visibility)
{
if(!Dispatcher.CheckAccess())
{
Dispatcher.Invoke(DispatcherPriority.Send, new UpdateControlVisibilityDelegate(UpdateControlVisibility), control, visibility);
return;
}
control.Visibility = visibility;
}

Obviously, this is called pretty easily via the code:

UpdateControlVisibility(_myLabel, Visibility.Hidden);

Nicely, even if this is called from another thread, it avoids the cross-threading issues.

But what about making it better? Using the tools available and going all Extension method on it’s arse??

Extension methods are (I think) great, even if Resharper is currently screwing up the intellisense for them! Anyhews, the basic signature we’ll be looking at for the method would be something like:

public static void UpdateControlVisibility(this Control control, Visibility visibility)
{
/* Code */
}

Two things different from the previous, first, it’s static, second it’s got the ‘this’ keyword in front of the ‘Control’ argument. OK, so now lets just plug in the code…

private delegate void UpdateControlVisibilityDelegate(Control control, Visibility visibility);
public static void UpdateControlVisibility(this Control control, Visibility visibility)
{
if(!Dispatcher.CheckAccess())
{
Dispatcher.Invoke(DispatcherPriority.Send, new UpdateControlVisibilityDelegate(UpdateControlVisibility), control, visibility);
return;
}
control.Visibility = visibility;
}

Ah. The biggest problem is that the method uses the ‘Dispatcher’ property of the Window class. As the extension method has to be in a static class, we don’t have access to the Dispatcher property… so… should we pass it in?

public static void UpdateControlVisibility(this Control control, Visibility visibility, Dispatcher dispatcher) { /**/ }

We could. It would work (or at least in my tests seems to), but would be a bit messy, ideally we only want to pass in the Visibility argument (remember as it’s an extensibility method, the ‘control’ part isn’t ‘passed in’). So. What to do? Luckily, the ‘Dispatcher’ property is actually on the Control itself, so we can modify the method call to be something like:

public static void UpdateControlVisibility(this Control control, Visibility visibility)
{
if(!control.CheckAccess())
{
control.Dispatcher.Invoke(DispatcherPriority.Send, new UpdateControlVisibilityDelegate(UpdateControlVisibility), control, visibility);
return;
}
control.Visibility = visibility;
}

The only real thing of note is that we’re using the ‘CheckAccess()’ method of the control rather than the Dispatcher’s. No real reason, just shorter to type, and does the same thing (or so reflector tells me 🙂 ).

So, now we can just get our Control based, err, controls to have their Visibility changed safely:

_myLabel.UpdateControlVisibility(Visibility.Hidden);

Good thing is that we can just whack this code into a utility project and utilise it where we want.

So – is this all good? Have we solved the problems of the world? No, sadly not. There are some caveats which you should be aware of. I originally attempted this so I could ‘Show()’ a Window safely. This led to me writing the following:

private static void ShowSafelyDelegate(this Window window);
public static void ShowSafely(this Window window)
{
if(!window.CheckAccess())
{
window.Dispatcher.Invoke(DispatcherPriority.Send, new ShowSafelyDelegate(ShowSafely), window);
return;
}
window.Show();
}

I was using this like this (you’ll have to bare with the threading here, it’s important to the story..):

///Handles the click of the button, gets the data on a new thread.
private void _btn_Click( object sender, RoutedEventArgs e )
{
Button b = sender as Button;
if(b == null)
return;
Thread t = new Thread(GetData);
t.Start(b.Tag);
}


///Gets the data and shows it in a
///The information to retrieve the data with.
private void GetData(object obj)
{
RetrievalInfo ri = obj as RetrievalInfo;
if(ri == null)
return;
DataTable table = DbUtils.GetData(ri);
WndwResults wr = new WndwResults(ri, table);
wr.ShowSafely();
}

Now, as we can see, the ‘GetData’ method is run on a seperate thread and constructs a WndwResults Window, and displays it (using the ‘ShowSafely’ method. Looks fine, but when run, will throw a tiswas and give you an:

InvalidOperationException
"The calling thread must be STA, because many UI components require this."

OK, so lets set the Apartment state of the thread to be STA…

Thread t = new Thread(GetData);
t.SetApartmentState( ApartmentState.STA );
t.Start(b.Tag);

GO!

ARGH!!!

LoaderLock detected
"Attempting managed execution inside OS Loader lock. Do not attempt to run managed code inside a DllMain or image initialization function since doing so can cause the application to hang."

???

What the hell does this mean??
Turns out that the Loader Lock is a system wide lock which Windows uses to load / unload dlls (http://www.lenholgate.com/archives/000369.html). As to what it’s doing here, well, I need to spend some more time investigating that. However, more importantly right now is what we can do about it?

Well, we can disable the Managed Debugging Assistant for the LoaderLock exception (via the ‘Debug -> Exceptions’ menu option), but when we do this, we see the Window we’re loading flash up and then dissapear – which isn’t exactly what we want… The other option is to change the code.

In my initial code, I created the WndwResults Window in the new thread. If I take this back a bit further, and construct the WndwResults in the main thread, (not ‘Show’ it, but just construct it) then we’re ok:

/* Simplified example */
{
WndwResults wr = new WndwResults();
Thread t = new Thread(ShowWindow);
t.Start(wr);
}


private void ShowWindow(object o)
{
Window w = o as Window;
w.ShowSafe();
}

The above code works fine, and that’s because we’re not constructing the Window in the new thread. Of course the issue here is that I can’t now pass the data into the constructor, which costs me a few things – use of ‘readonly’ for the members, and other such things. But we can live with that.

Soooo….

We add a ‘SetData’ method to the Window:

public void SetData(DataTable table, RetrievalInfo ri){ /*....*/ }

and, going back to our previous code:

///Gets the data and shows it in a
///The information to retrieve the data with.
private void GetData(object obj)
{
RetrievalInfo ri = obj as RetrievalInfo;
if(ri == null)
return;
DataTable table = DbUtils.GetData(ri);
_wndwResults.SetData(table, ri); //
_wndwResults.ShowSafely();
}

Run the code… and… FFS!!!

InvalidOperationException
"The calling thread cannot access this object because a different thread owns it."

Of course it does! Hmmm, not a lot can be done in this situation, because the SetData (in my case) sets a couple of DependencyProperties, which in turn update the UI.

What can be done though? Well – we can make the SetData method literally only set member variables, and then attach to the ‘Loaded’ event of the Window in it’s own constructor, so… if it originally did this:

public void SetData(string message)
{
_lbl.Content = message;
}

Now it needs to do this:

//First add the member:
private string _message;


//Second add to the constructor of the Window and event handler.
public Window1()
{
InitializeComponent();
Loaded += Window1_Loaded;
}


//Handle the event...
private void Window1_Loaded(object sender, RoutedEventArgs e)
{
_lbl.Content = _message;
}


//Finally, modify the SetData method to actually set the data.
public void SetData(string message)
{
_message = message;
}

Phew! Lots of stuff to do, and that’s just for setting a label!

What are the conclusions of this epic of blog posts?
Well, quite frankly, going down the extension method route, whilst informative in learning how the threading works (well, a bit) has given me some useful methods, but, there are a lot of caveats that a Window has to adhere to, to make it work properly.

I’m going to persevere with this though, I reckon I can at least get some decent set of utility extension methods (for example the setting visibility one) for WPF controls. I’ll keep you posted – you never know, it might even be more frequent than once a month!

Managed Application Framework – Part 1 – The Beginnings!

Last week I was tasked with developing a new App for the guys I work with, (not a developers app you understand, but for actual normal users!!! Luckily it puts me smack bang where I work best – developing functional, extendable (and most importantly) Windows based apps. I’m now officially in my comfort zone!

The main difference between this app and previous apps I’ve done is the customer, normally I’m the person who writes that software tool that the other devs or system admins will use, so I can cram in shed loads of functionality and what I think are cool UI’s – usually involving liberal use of the SandDock tools (http://www.divelements.com/). This time because the users are non-expert users I’m having to really consider the design of the UI, and it is (in this case) very important – one of the specs of the app is: ‘It has to look cool’.

There is actually a reason for it to look cool – because we need it to impress management to get the go-ahead to redo an older app. Up side of this is that it’s going WPF. Aces!

Woah, I appear to have got a little bit sidelined.. I actually started this post to talk about the Managed Add-In Framework (MAF) of .Net 3.5. The MAF is a framework for using Add-In’s (or plugins as some apps call them) within .NET, but without the hassle of writing your own code to do the cool stuff (reflecting to load dlls etc).

As it happens MAF fits very nicely into the app I’m designing at the moment, so I’ve been playing around with it for a week or so now, and I have to say, I’m very impressed, the design of the MAF has been extremely well thought out, and covers a hell of a lot!

What does MAF consist of? Basically 3 broad parts, Host – Pipeline – Addin, of which the pipeline can be broken down into: HostView – HostAdapter – Contract – AddInAdapter – AddInView. The reason this is important is that the pipeline seperates the Host and AddIn from being dependent on the Contract (which in a later post will prove to be incredibly useful).

In this post (below) I’m going to explain how to set up a simple quick MAF application, just to get the swing of things, so.. without further ado: the MAF.

Firstly it’s important to know that the MAF requires a certain folder structure to work, (I think it requires it, every example, sample etc I’ve seen has it!). The structure can be seen on MSDN at: http://msdn2.microsoft.com/en-gb/library/bb384240.aspx – This is why I’ve put the fact that you need to set the output folders in the properties for projects created to point to a non-default location.

We begin creating a MAF project with a Class Library project we’re gonna call ‘Contracts’. In it we define the contract we intend to make all our Add-Ins implement.

  1. New Class Library – ‘Contracts’, set the Build Output to be: ..\Output\Contracts
  2. Add references to: System.AddIn and System.AddIn.Contract
  3. Define new interface, which must implement the IContract interface, and have the AddInContract attribute.


[AddInContract]
public interface IHelloMAFContract : IContract
{
string HelloMAF();
}

  1. Build the one project, all ok? Good, let’s mosey on!
  2. Get and install the Pipeline builder (open source) from codeplex: http://www.codeplex.com/clraddins
    (All the instructions are on the interweb at that site).
  3. Run the Pipeline builder and create the pipeline, this creates the 4 extra projects (HostView, AddInView, AddInSideAdapters and HostSideAdapters projects). This saves us the time of writing this code ourselves (which involves quite a lot of code repetition).
  4. Build the solution, you should have 5 projects now. Assuming that went ok, lets carry on.
  5. Create an Add-In —
    a) Add a new Class Library project to the solution, call it something like ‘AddInV1’
    b) Set the build output location to be: ..\Output\AddIns\V1
    c) Reference in the AddInView DLL which will be in the Output\AddInView directory.
    Set this reference’s ‘Copy to local’ property to ‘FALSE’.
    d) Reference in System.AddIn
    e) Edit the class file and create the code to implement the IHelloMAF contract:


[AddIn("AddInV1", Version="1.0.0.0")]
public class AddInV1 : IHelloMAF
{
public string HelloMAF() { return "Hello MAF!!"; }
}

In this code we’ve attached the ‘AddIn’ attribute, which takes a name (which can’t have spaces) and then a set of named properties (intellisense is your friend here). Also of note is that in our ‘Contracts’ project we called the contract: IHelloMAFContract, whereas here we’re using IHelloMAF. The code does nothing impressive, just returning a string.

  1. Build the solution, if you look in your output folder you should now have a \Addins\V1 directory with the dll in it. That’s the Add-In created.

  2. Now we’re going to create a host to actually run the Addins
    a) Create a new Console Application (call it something memorable, ‘host’ for example :))
    b) Reference the HostView dll (copy to local = false) and the System.AddIn dll.
    c) Set the build output location to: ..\Output
    d) In the Program.cs file, put in the following:


public static void Main()
{
string path = Environment.CurrentDirectory;
//Update the AddInStore looking for the AddIns.
AddInStore.Update(path);

//Get the tokens from the AddInStore.
Collection tokens = AddInStore.FindAddIns(typeof(IHelloMAF), path);

Console.WriteLine("Found " + tokens.Count + " addins, activating them....");

foreach(AddInToken token in tokens)
{
//Activate a given token.
IHelloMAF addin = token.Activate( AddInSecurityLevel.Internet );
Console.Write( "\tAddin: " + token.Name + ", version: " + token.Version + " --> " );
Console.WriteLine( addin.HelloMAF() );
}

Console.WriteLine();
Console.WriteLine( "Fin. Press ENTER to exit." );
Console.ReadLine();
}

What we have here are 3 main points, firstly where we do: AddInStore.Update(path); We’re telling the AddInStore to update itself and look for AddIns with the given root path.

Next point is the AddInStore.FindAddIns(typeof(IHelloMAF), path); line, which basically asks the AddInStore to find the AddIns available of a given type.

The final point is the activation of the AddInToken – token.Activate( AddInSecurityLevel.Internet );. At this point we’re activating the Add-In, and in the next lines calling methods on it.

  1. Build the solution.
  2. Start debugging (F5).

Running this should now give us:

> Found 1 addins, activating them....
> Addin: AddInV1, version: 1.0.0.0 --> Hello MAF!!
> Fin. Press ENTER to exit.

That’s the basic Host Pipeline AddIn structure, and will provide you with a good basis, the next step is to consider what to do in the event that we want to change the contract…

Printing a word document from C# – how the **** do you change the paper type???????

You wouldn’t have thought it would be that hard to print word documents from within C# – hook up the project to the Word Interop dlls – open the document and print. Easy.

In fairness – a lot of it is like this – and setting up a printer is pretty easy;

PrintDocument pd = new PrintDocument();
pd.PrinterSettings.PrinterName = printerName;
word.ActivePrinter = printerName;
word.PrintOut(....)

Even selecting a given tray is manageable – either via the ‘WdPaperTray’ enum – or even searching for it via a string.
But try as I might – I cannot find a way to change the paper type – and by that I mean from ‘Plain’ to ‘Preprinted’.

The basic problem is that I need to print to (say) ‘Tray 1’ which contains ‘Preprinted’ paper – and is set up as so on the printer. Attempting to print a plain paper printout gets stuck at the printer with a Paper type is mismatched error – which is fair enough.

Does anyone know how to do this????

WPF Resources from other DLL’s

I spent a little bit of time trying to figure this out, to be honest – it’s available in quite a few locations on google, but I thought I’d add it here as well. The basic problem is, you have your template / theme etc for your control in a separate project;

MyThemes : DateTimeThemes/Theme1.xaml etc

and you want to use this as a resource for your control, how?

You add into your Resources element (be it in Window.Resources or UserControl.Resources), like so:

<ResourceDictionary Source="/MyThemes;component/Themes/Theme1.xaml" />

What’s important here is that the word ‘component’ is as spelt, you don’t replace it with anything (like ‘MyComponent’ for example), just leave it as is.

/MyThemes

is the name of the dll, which isn’t necessarily the name of the project – (though that would only change if you’ve changed those properties).

Functional Programming in the .NET World…

Recently a post from one of my ex-colleagues got me interested in working my way through a set of problems at the ‘Project Euler‘ site. He piqued my interest, and I started working my way through them (not at any great speed mind – I’ve only done 4 so far – and I’ve been doing it for 3 days!!).

Then he posted another post about the problems and solving them in a functional way rather than errr…. non-functional – thanks Steve! Now I feel compelled to look into the functional world, and with good reason from a .net development point of view.

F# is the Microsoft Research functional language, and is designed to fit in nicely with the .NET framework, and (indeed) Visual Studio. To be honest, I haven’t explored much beyond looking at the examples and playing with them – but it looks good. In line with what Steve (hackinghat.com) said, I too haven’t really played with functional programming since uni, though in my case, that’s only 4-5 years ago now 🙂