I wrote a VSIX!

It’s been a long time since I extended Visual Studio, and I have to say, the experience has gotten a whole lot better.

I’ve been doing a lot of work with JSON dates (more information about this at the end, but stick with me for the journey first). The problem is that they are not very human readable. Who knows when this date is for?

{ “date”: “/Date(1346713200000+0100)/” }

So initially I came up with the idea of a tool window where I could convert them over, but a quick hunt on MSDN led me to https://docs.microsoft.com/en-gb/visualstudio/extensibility/walkthrough-displaying-quickinfo-tooltips. It looks like this would be even better.

So now I have


You can see the code at https://github.com/alski/JsonQuickInfo. All of the action takes place in lines 31-91 of JsonQuickInfo.cs, and yes I will refactor that very soon!!


VS2017 – Oh so you zoomed in by accident…

One of the really nice things about VS2017 is the ctrl+. functionality. It takes away a lot of the need for ReSharper, so much so that I’m currently trying to see if I can live without R# on one of my installs.

However, if you are as fat fingered as I am then you’ve probably also found the ctrl-shift+. key combination and now you have a quandry.

Firstly, your screen just zoomed in and while you quite like it, you want it to go back. Ctrl-Shift-, isn’t bound to anything that would be too obvious. So you reach for the mouse and hit the drop down and all is well again, until you fat finger again.

Maybe if you search in ctrl-q you can find out what happened? Nope.

“Zoom” seems to give no results except for search NuGet (and I’m on a very flaky mobile connection here). Nor “enlarge”, “view” argh!!!

About this point I searched the Tools->Options->Keyboard settings until I uncovered that Ctrl-Shift+. is bound to View.Zoomin, and Ctrl-Shift+, isn’t bound to anything.

So here’s the choice.

Bind Ctrl-Shift+, to View.Zoomout, or unbind Ctrl-Shift+.

Personally, I quite like this keyboard zooming lark, and just need to found out if VS syncs this setting properly…

UWP Combobox SelectedItem doesn’t bind

I’ve had problems using UWP ComboBoxes, the symptoms being that even by Binding the SelectedItem, nothing would be selected in the ComboBox when it was displayed. Sometimes this showed as, you could select something go, leave the page and return and the selection would be cleared, or even worse, it works on some visits to a page but not others when you hadn’t changed the selection.

So here’s some causes.

The collection items changes

Illistrated as an example on Stackoverflow. Basically if you re-create your collection items then it is impossible for selected item to be found in it, i.e. it looks like SelectedItem uses ReferenceEquals to find the item in the collection.

So this code has problems because it recreates the collection AND its items on every get,

public Item[] Items => new[] 
    new Item {Index = 1}, 
    new Item {Index = 2}, 
    new Item {Index = 3}, 
    new Item {Index = 4} 

but this is fine as the strings are constant, even though the collection changes

public string[] Strings => new[] {"1", "2", "3", "4"};

You specify a field instead of a property

I have no idea why this doesn’t work, but… if you specify a field

public string[] Strings = {"1", "2", "3", "4"};

then the binding will fail to select the items again, it needs to be specified as

public string[] Strings {get;} = {"1", "2", "3", "4"};

You specify the XAML in the wrong order

This is the massive WTF, and yet it is quite obvious really. I had the following code

<ComboBox SelectedItem="{x:Bind FirstItem}" ItemsSource="{x:Bind Items}"> ….

When you NEED to have

<ComboBox ItemsSource="{x:Bind Items}" SelectedItem="{x:Bind FirstItemMode=TwoWay, Mode=TwoWay}">

In this case, during the bind of the SelectedItem it is checked against an empty collection, and as a result, the selected Item ends up being set to null. Then the Items are bound.


One thing that helps is that if you switch your binding to Mode=OneWay then the binding will display correctly in the ComboBox (but obviously won’t update). Which does at least give us a starting point.