Monthly Archives: February 2013

You Can Change This Later

I am terrified of forms that ask me to name something. Why? Because I fully expect that once I’ve chosen that name it is locked in forever. This fear drives me to put off taking action in certain circumstances until I am sure that the name I have chosen is just right.

The common scenario is that I have some great idea. So I come up with a working title and start sprinkling that title in various places. Invariably I discover that my working title was lame and so I need to come up with a better name. Unfortunately I can’t, I’m locked in with a working title – hence my fear of choosing a name.

As a purely practical measure I avoid using real product names in code, instead coming up with some kind of tangentially related code-name for namespaces and other identifiers. This works sometimes, but eventually you have to commit.

Seriously – why are so many names that we chose immutable? If I provision a hosting account with specific domain name, why can’t I change the name later on? What seems worse is that the forms that collect these details don’t seem to tell you that the name is irreversible and can’t be changed.

What I would like is some kind of special icon that you put next to text boxes which force you to choose names that get locked in – maybe a picture of a foot nailed to the floor. Or instead – maybe we could actually make our software easier to use and allow users to change key identifiers and instead use some kind of artificial key to identify the data. I’m pretty sure we have the technology to do this ūüôā

F12 Developer Tools for Apps for Office

… or lack thereof!

Yesterday I posted up about Apps for Office, and included a little demonstration of how to hook selection events in Excel. Pretty trivial code to write. However one of the things that I was concerned about was debugging layout issues within the app container (an embedded browser) running in Excel.

Turns out after a little investigation that a new feature within Visual Studio 2012 nicely solves this problem. The feature was introduced to help developers who are building Windows 8 Store apps using HTML+JS – in that environment you can’t hit F12 and bring up the developer tools either.

The DOM Explorer window can be brought up from the “Debug | Windows | DOM Explorer” menu option when you are debugging an application. To demonstrate, I’ve uploaded a video which goes along with my sample code up on GitHub.

One thought I do have is whether this might be useful for debugging any embedded IE browser in any application – that would be cool! My experimentation indicates that some extra work might be required to open the application up for debugging that way. Anyway – this solved my immediate problem!

DocumentSelectionChanged in Apps for Office

I have just posted a sample of how to hook the DocumentSelectionChanged event in the new Apps for Office programming model.

For the last two days of this week I am attending some training being put on by Microsoft around their new application framework being delivered with Office 2013 and SharePoint 2013. We’ve just taken the high level tour through the new Office 2013 application model. I’m really excited because it is just HTML + JavaScript running off a web-server rendered inside an office app. Integration between your code (JavaScript) and Office is achieved through a JavaScript library (JSOM).

To test our my new-found knowledge I slapped together a quick little demonstration which runs inside Excel 2013 records the various cell selections that users make. You can pull down the source from the ExcelSelectionChangedDemo repository on GitHub.

To get up and running with this on your local machine you are going to need a few things:

Given I am using a Git source code repository hosted up on GitHub you might also like to consider downloading the Git extensions for Visual Studio.

Getting back to the new application model. Apps for Office are literally just web-pages which pull in a special JavaScript file (office.js) and which is hosted within a frame within Office.


In the screenshot above you can see the previously referenced code running in Excel 2013. The code that drives this is in the Gist below.

Looking through the code you can see that the HTML file is just referencing a bunch of JavaScript libraries and has some HTML which represents the UI. The interesting thing here (other than it runs in Office) is that they aren’t stopping me using any of the JavaScript libraries that I know and love – for example Knockout.js or jQuery (in fact the samples use jQuery by default).

The other file in the Gist (ExcelSelectionChangedDemo.js) is just a plain old JavaScript file. Let’s go through this one in a little bit more detail. On line 13 we register a function with the JSOM API (JavaScript Object Model for Office). In this case we are just telling Office to let us know when it is loaded so we can register a hook for the ready even from jQuery. The active ingredient is actually on¬†line 20 where I can register to receive an event from Office when the¬†DocumentSelectionChanged event is fired (EventTypes).

The SelectionChanged method handles the callback (line 27) and then uses JSOM to fetch the data that has been selected. This is a two step process. First you get notified that a data selection changed, then you ask the object model to give you the selected data via getSelectedDataAsync. As the name suggests, this is method asynchronously fetches the data so a callback is provided (in this case, DataSelected).

The DataSelected method takes a single JavaScript object which specifies the outcome of the call. If the call succeeded you will be able to get the data, if not, you will get some error details (refer to AsyncResult for details). Reasons for this call failing might include that you have asked the data to be coerced into a format that is not appropriate given the content selected in the document.

The rest of the code in the ExcelSelectionChangedDemo.js file is just code which drives Knockout.js to deliver data-binding. Each time the selection changes inside the Excel application a new element is added with a JSON representation of the AsyncResult object. Selecting any cell, or multiple cells in a rectangle on the screen should result in a successful output. If you use CTRL-click and select multiple random cells around the screen you should be able to trigger an failure.

I’m going to keep looking into the new application story around Office and SharePoint. I think it is a really positive step forward for Microsoft which might help win back some mind-share from web-developers. I hope the same that I created helps you get started too.

Thanks to Michael Stokesbary, Yina Arenas, and Russell Palmer for running the event. Also I just noticed that one of my¬†colleagues¬†at Readify, Jake Ginnivan is doing a presentation titled “Removing the shackles of the past – Office and SharePoint development in the Cloud” in Perth on the 12th of February. Check it out if you are interested and in the area.

The NFC wave is coming…kinda.

I stepped out yesterday morning to go to an appointment and when I got back I dumped my wallet on my desk then neatly stacked my phone on top of it. I’ve got a Nokia Lumia 920 running Windows Phone 8. After a second my phone chimed. I was familiar with the noise because I have a wireless charging stand by my bedside table.

Turns out that the NFC proximity sensor on the Nokia Lumia 920 had picked up an NFC chip from the many cards within my wallet. This afternoon I sat down to figure out which card it was and how I could use the proximity API within Windows RT to read the card.

As I flicked through the cards in my wallet and held them out to my phone I found that if the 23 cards in my wallet, six of them had NFC chips within them. Of those there were 3 bank cards, 2 transport cards and 1 loyalty card.

My next goal was to figure out how the proximity API within Windows Phone works to see whether I could get access to any of the details on the cards. I’ve slapped together a quick example of how to use the proximity API. The code uses the ProximityDevice and hooks up to the DeviceArrived and DeviceDeparted events and also calls SubscribeForMessage.

Unfortunately none of the cards that I had in my wallet contained an NFC device which was in a format that Windows Phone 8 could understand. NFC messages that Windows RT supports are listed on the PublishBinaryMessage documentation page. From what I can tell Windows Phone 8 only supports a subset of these, and other than Windows specific message types, the messages need to be formatted using NDEF. If you happen to have an NDEF formatted card you can use the NDEF library hosted at CodePlex to work with the data directly.

I hope that in the future Microsoft will open up more of the NFC device capabilities on their mobile platform. I suspect that many loyalty card programs that use NFC won’t necessarily encode their messages with NDEF which will limit the ability to do anything interesting with Windows Phone unless they take the step to redistribute cards (unlikely).

Either way, I think that we are going to see more and more NFC moving forward. It is already quickly taking hold with credit card/over-the-counter transactions, but so much more is possible with mobile integration. Maybe I’ll look at using NFC in between mobile devices next. The NFC wave is coming…kinda.