Visual Studio Tip #2: Pin your data tips

[cross posted from my MSDN blog]

Most people know that when you are debugging, you can hover the mouse over a variable in your code and the tool tip will provide you the current value.

For example, if I hover over the “uri” variable below it shows me that it’s current content is “”


That is very helpful, but what if I am going in and out of this code very often. Say I’m calling the function multiple times and I want to see this value each time. I want to quickly glance at the value instead of having to hover and wait.

I could use the Watch Window and add the uri variable to that. Then it would always show me the value but its not as convenient as it could be.

Look at the right end of the data tip. That is a pin! Click that.


Now the value is pinned in place right where I can see it – no hunting for it. It is pinned to line 30 and will stay there while I’m in debug mode (even if I stop and restart debugging). It will update in real time and, because it is right in the code, I have the context to know exactly what it is for.

In addition, if I hover over the pinned data tip, I can add a comment to help me remember why I pinned it there.


For more on Data Tips, see the documentation

This post is part of a series of Visual Studio tips. The first post in the series contains the whole list.

Posted in VSTips | Leave a comment

Back to basics: Visual Studio tips

[cross posted from my MSDN blog]

Lately I’ve been working a lot with developers who are completely new to C# and/or Visual Studio. So I’ve been trying to gather some features and workflows which I’ve seen new users overlook which will make them a little more productive. A large amount of “a little more productive” turns into  “very productive” very quickly. 

To me its not about knowing how to do something. Its knowing that you can do it at all. This will be my list of those things. Some will be short and sweet others will be longer. Some have been in Visual Studio for a decade and some are new. Even if you are an experienced Visual Studio user, at least glance at the titles because you never know what you don’t know. Or you may read one and have a better way to do it. If so, let me know in the comments and we can all learn together.

As I add tips in subsequent posts, I’ll add a link here so it has the whole list in one place.

OK, on to tip #1!

Visual Studio Tip #1

Install the Productivity Power Tools

The first thing I do after installing Visual Studio, is install the power tools. This is a set of extensions provided by the Visual Studio team that add additional functionality to Visual Studio. There have been a set of power tools for each version of Visual Studio since 2010 and often the power tools features make there way into the next version of Visual Studio. So it helpful and like a little glimpse into the future.

You can get a full list of the features it adds at its page in the Visual Studio Gallery so I’m not going to go into detail about them here. I’m just going to say – install it. You can thank me later.

You can install it from the page in the Visual Studio Gallery but the easiest way is to just have Visual Studio kick off the process for you. Select “Extensions and Updates” in the Tools menu.


Then make sure you have the “Online” tab selected in the left panel and search for Productivity. When you find it, click the Download button to start the download and run the installer.


You will probably be asked to restart Visual Studio after the install is completed. From then on, Visual Studio will notify you if there is an update to the tools.

Posted in VSTips | Leave a comment

Speaking Zork

How do you update an old-school text adventure game to run on a modern smartphone? You teach it to talk.

This is an update to an idea I was playing with a few years ago. I ported a Z-Machine interpreter to Windows Phone to see if you could play a text adventure on a device with a virtual keyboard. It seemed to work fine and then went into the closet until last week when I was thinking about the new voice functionality in Windows Phone 8.1. So I got out the app and spent about an hour upgrading it to Windows Phone 8.1 and adding the speech recognition and the text to speech functionality.

The surprising thing is how well it works. There are a few methods you can use to do speech recognition on Windows Phone. I used the simplest one, the generic recognizer (so I didn’t have to tell it what words to listen for) – and it works great. It was so easy I’m surprised its not found in lots of more apps in the store.

Posted in Dev Stuff, Tinkering, Windows Phone | Leave a comment

Tasks and awaits and Rx! (And Drones!) Oh My!

(cross posted from my MSDN blog)

A few people I work with are tinkering with an off-the-shelf drone in our spare time and so we are writing a C# library to control it.

The way it works is you send UDP commands to the drone and you receive a stream of status & navigation UDP packets from it. So everything is asynchronous by default. You don’t send a command and get back an “I got it!” response. You have to send a command and then monitor the status for a change reflecting your desired state,

For example, to start flying, you must repeatedly send the “take off” packet every few milliseconds until you see the “is flying” flag set in the status packets. Lets see what that would look like.

We want the SendCommand method to be asynchronous and totally decoupled from the UI. So the send process looks like this.


When we call SendCommandAsync() the command gets queued and the method returns immediately. Then there is a Task whose sole job is to take commands out of a queue and send them to the drone. This keeps them in order but prevents the caller from waiting behind anything that had previously been queued.

Now that SendCommandAsync() is async, the trick is “how do we know when the command has actually been sent?” Well we can use a TaskCompletionSource and queue it with the command. Then the worker Task sets the completion when it actually sends the command.

 1: public Task SendCommandAsync(DroneCommandBase command, CancellationToken token)

 2: {

 3:     TaskCompletionSource<object> tsc = new TaskCompletionSource<object>();

 4:     this._cmdQueue.Add(new CommandInfo()

 5:     {

 6:         TSC = tsc,

 7:         Cancel = token,

 8:         Command = command,

 9:     });

 10:     return tsc.Task;

 11: }


1: success = this._cmdQueue.TryTake(outcommandInfo);

 2: if (success)
 3: {
 4:     // send the command data
 5:     this._cmdWriter.WriteString(commandInfo.Command.ToString());
 6:     await this._cmdWriter.StoreAsync();
 7:     // signal completion of the send Task
 8:     commandInfo.TSC.SetResult(new object());
 9: }

(As an aside, this is an excellent example of when Tasks are not Threads. We can dump 10,000 commands into the queue and get 10,000 Tasks but will never generate a new thread. The Task represents the completion of the operation “Send a command to the drone”.)

Now that we have an async send command we can start to build on top it in a very natural way. The Take Off procedure requires us to send the command multiple times until it takes off. So we can add a method that sends multiple commands until a cancellation is requested

 1: public async Task SendRepeatedCommandAsync(DroneCommandBase command, TimeSpan delay, CancellationToken token)

 2: {

 3:     while (!token.IsCancellationRequested)

 4:     {

 5:         await SendCommandAsync(command, token);

 6:         await Task.Delay(delay);

 7:     }

 8: }

then we can add a method to provide a condition upon which the send will stop repeating

1: public async Task SendRepeatedCommandUntilAsync(DroneCommandBase command,

TimeSpan delay, Func<NavData, bool> condition, CancellationToken token)

 2: {

 3:     var localCTS = new CancellationTokenSource();


 5:     var navDataStream = from data in NavigationDataStream

 6:                         where condition(data)

 7:                         select data;


 9:     // start the repeated command sequence

 10:     SendRepeatedCommandAsync(command, delay, localCTS.Token);


 12:     try

 13:     {

 14:         // Take(1) so that the sequence ends after the first item

 15:         await navDataStream.Take(1).ToTask(token);

 16:     }

 17:     catch (TaskCanceledException cancelEx)

 18:     { 

 19:         // the caller cancelled the operation

 20:     }

 21:     finally

 22:     {

 23:         // stop the commands from repeating further

 24:         localCTS.Cancel();

 25:     }

 26: }

Notice we are not ‘await’ing the SendRepeatedCommandAsync call. We just want to initiate that process and will cancel it when we are ready. Also in this case I’m using Reactive Extensions to model the navigation data stream. It is an asynchronous stream so its feels natural and provides a nice LINQ experience on top of it. NavigationDataStream is defined elsewhere as IObservable<NavData>.

Now from a higher level we can write this code to perform the take off.

 1: public async Task TakeOff()

 2: {

 3:     Command takeOffCommand = new Command(Argument.TakeOff);

 4:     await _connection.SendRepeatedCommandUntilAsync(

 5:         takeOffCommand,

 6:         TimeSpan.FromMilliseconds(20),

 7:         data => (data.drone_state & (uint)Constants.FLY_MASK) == (uint)Constants.FLY_MASK

 8:         );

 9: }

This describes exactly what I want, send the command every 20 milliseconds until the drone state shows that its flying. Following that pattern of thought, I can later start composing other items and scripting things

 1: public async Task SampleScript()

 2: {

 3:     await _droneController.TakeOff();

 4:     await _droneController.FlyForward();

 5:     await Task.Delay(5000);

 6:     await _droneController.FlyBack();

 7:     await Task.Delay(5000);

 8:     await _droneController.Land();

 9: }

Broken down, each function is simple enough to understand and debug. This simplicity only comes from the power of Rx, the TPL and the async/await functionality. Imagine what the code would look like before when all the timers and .NET events and state would have to be managed directly.


Small disclaimer: all this code was written *without* the drone to test it (Its in Seattle and I’m in Dallas). So while the logic is sound and it compiles I haven’t been able to test it outside of a simple console app harness. Any glaring issues that arise due to eagle eyed commenters will be corrected. Even so, the larger point is that async/await is much more than just “do an async call here.” The concept of creating your own Tasks to represent your own operations becomes a powerful mechanism that allows easier higher level composition logic.

Posted in Dev Stuff | Leave a comment

480px update….

I do have an updated version I’ve been running on my personal phone for a while. I just need the time to sit down and polish some things and then I’ll get it released.

Posted in 480px, Windows Phone | Leave a comment

Thoughts on async/await in C#

I’ve changed the language that I (and others) use to describe this functionality in C# because it sometimes doesn’t quite hit the mark. And actually can cause new users of it to believe the wrong thing is happening. More details here

Posted in Dev Stuff | Leave a comment

Chain It! game for Windows 8 now in the store!

OK, I finally got something submitted to the Windows Store. Its a simple game of tapping tiles in order and trying to get the longest chain you can. Give it a try at
Its simple now (just 4 game modes) but there is more stuff planned…
Posted in Chain It!, Windows Store | Leave a comment