Teamprise will be exhibiting at the Chicago launch event tomorrow, March 11. We're in booth 47 - stop by and say hi if you're attending.

Even better -- our very own Martin Woodward will be presenting at the Dublin launch event tomorrow. Be sure to check him out if you're attending out there.

Otherwise, there are still plenty of events in a city near you - be sure to go check out what's new in TFS 2008!

But I'm not going to lie, I'm really put off by the advertising. This year's theme for the conference is Alan Turing. How this conference has been going on for 14 years and ignored him up to now is a mystery to me. (They made a carrier pigeon the theme in 1997. That's right, a carrier pigeon apparently did more for security than Turing.)

But now that RSA has finally decided to recognize the man, they're doing some stupid advertising around it: What Would Turing Do? Which, frankly, would make a cool bumper sticker, and I would have been impressed... if they had just asked the question and not tried to answer it.

Instead, they give some odd answers that show that their marketing department never bothered to talk to a developer - or even a read a Turing biography. Their answers are frequently bizarre and have nothing to do with Turing: he would "have a raging sushi addiction", "be a huge Dr. Who fan" and would "collect rare Phillip Glass vinyl". (Yes, they also didn't bother to google "Phillip Glass" to realize that they misspelled his name.)

This is the company that was founded by three math PhDs who invented the RSA public key algorithm the RC block ciphers, and the MDx hash functions. And they're suggesting that he would "recite the far reaches of imaginary numbers to pass the time"? I'd like to think that would be beneath Turing... hell, it would be beneath me. (A googleplex times i. A googleplex plus one times i. See, not very satisfying is it?)

Very disappointing.

Especially since it's obvious that really, Turing wouldn't care about sushi or Bill Gates. He'd be far too busy enjoying the liberal sexual mores of this fine time we live in.

When working on native code, I tend to make all my code work in C first - debug it, write some native test cases, and ensure that everything works. Then I write a little JNI glue to make it accessible from Java. This has worked surprisingly well, and given few surprises. But what happens when something goes wrong?

For example: I was writing some ugly Win32 code to do some various things that can only be done in C. Despite my aversion to programming in Windows, I whipped up some native code to access what I needed. I wrote some test cases to confirm that everything worked, and I was pretty happy with myself, until I realized that all the work I had done was on ANSI C strings (ie, null-terminated char arrays.)

Regardless, I tied it up to my Java with some JNI code just to watch it fail when I passed in Unicode strings.

I'm not particularly well-versed in the intricacies of Unicode, and even less so Win32 programming with its WCHARs and PSEC_WCHARs and nasty habit of #define'ing function names to those that end in W. So I wasn't real sure of exactly what I needed to change to make my native code Unicode friendly. It sure would be nice if I could debug this in VisualStudio.

Attaching to a running process in gdb is easy - and it's easy to provide debugging symbols for that process. VisualStudio is a little less straightforward, but just as easy.

First, make sure that your DLL is emitting debugging symbols. Ensure that you're passing these flags to the compiler and linker:

CFLAGS: -Od -DDEBUG -D_DEBUG -Zi
LFLAGS: -DEBUG

Build your native DLL and ensure that a .PDB file was created - this is the debugging information for your library. Run your java application.

Open VisualStudio and setup your symbols. Go to Tools -> Options, and open the Debugging -> Symbols pane. Add a new PDB location which points to the PDB file that was created from your build.

Now you can attach to your java process by going Tools -> Attach to Process.

Finally, you can load the source (ensure that this is the source you built from, in the same directory as your PDB file) and set breakpoints, etc.

Teamprise was invited to present at this month's Chicago VSTS Users Group to discuss using TFS from within the Eclipse IDE and from non-Microsoft platforms. I'm excited to make a fool of myself speaking in public (and excited to learn that a VSTS Users Group exists in Chicago.)

I'll be speaking with David Dugan who's a Senior Consultant for Sogeti. David will be discussing accessing TFS from older versions of Visual Studio.

Maybe I'll see you there!

Perhaps this dialog doesn't look particularly strange, until you realize that the install disc only included four CD images:

(This was the MSDN install for Vista.)

(From the Matchbook Museum)

Wait, you're not? Then this post probably doesn't interest you too much.

But if you are, there are some UI changes in the way Eclipse 3.3 starts up that you should be aware of.

Likely, your application has a subclass of WorkbenchAdvisor, probably called something like YourWorkbenchAdvisor. And this is doing various useful things like creating views and setting preferences, all that good stuff. And maybe you're overriding WorkbenchAdvisor.postStartup() to do some useful things after the Workbench has started.

Maybe one of those useful things happens to be raising a Dialog. In versions past, this would have worked fine for you. In Eclipse 3.3, you may be in for a rude awakening. Despite the name, the Workbench has not started and the UI is not fully functional when YourWorkbenchAdvisor.postStartup() is called.

In particular: other threads cannot call back into the UI thread with Display.asyncExec() or Display.syncExec(). The UISynchronizer will queue up any runnable you post on to the UI thread to run once it actually has started. This can present a problem if the dialog you raise fires off a background thread to do some work.

For example, in Teamprise Explorer our login dialog has an option to test your connection to the TFS server. This involves firing off a background thread to look at your network settings, try to connect, etc. The results of these test are then posted back to the dialog using Display.asyncExec().

What happens in Eclipse 3.3? Since the login dialog was started from our postStartup() method, the UISynchronizer hasn't started. So when we call Display.asyncExec() to display our results, they're put in a queue to display once the UI has fully started. This, of course, only occurs after you've closed the login dialog, at which point there's no dialog to display these settings to.

Ouch.

To combat this, you should move any UI code out of YourWorkbenchAdvisor.postStartup(). You can either do this by putting your code in the UI queue to execute as soon as the Workbench starts fully, or you can move it out of postStartup() entirely and use a different hook to raise your UI once the Workbench is started.

These options are both sort of a hack, so you're welcome to use whichever you find less obscene:

1. Queue your UI code in the UISynchronizer, where it will be run as soon as the Workbench is started
   If a non-UI thread calls Display.asyncExec() before the Workbench startup has completed, your Runnable will be queued to run after the Workbench has started, but this is only true if it's called from a thread other than the UI thread. So you need to get off the UI thread to post this into the queue. Firing off a new thread from your postStartup() method should do the trick:

   new Thread(new Runnable() {
       public void run()
       {
           Display.asyncExec(new Runnable() {
               public void run()
               {
                   // do something on the UI thread
                   // after Workbench startup
               }
           });
       }
   }).start();

   This will put your inner Runnable on the UI queue to execute as soon as Workbench startup is complete. (Had you called Display.asyncExec() from the current thread, it would execute immediately.)

   If you don't like the idea of stuffing a Runnable inside another Runnable, there's a second option:

2. Override WorkbenchAdvisor.eventLoopIdle() to call your code the first time the UI is idle
   
   If you look closely at Workbench.runUI(), you'll see that the UISynchronizer isn't started until right before a call to Workbench.runEventLoop(). So hooking in to WorkbenchAdvisor.eventLoopIdle() is your first opportunity to execute code once the UI thread is properly started.

   Adding this to YourWorkbenchAdvisor should be sufficient:

   private static ThreadLocal eventLoopStarted = new ThreadLocal() {
       protected Object initialValue()
       {
           return Boolean.FALSE;
       }
   };

   private void start()
   {
       // do something on the UI thread after Workbench startup
   }

   public void eventLoopIdle(Display display)
   {
       // the ui is now started, we can do our work
       if(eventLoopStarted.get().equals(Boolean.FALSE))
       {
           // call any post-startup UI
           start();
           eventLoopStarted.set(Boolean.TRUE);
       }
       else
       {
           // default: yield cpu until new events enter the queue
           super.eventLoopIdle(display);
       }
   }

   I'm synchronizing on the eventLoopStarted flag, which is probably not necessary since only the UI thread should be calling eventLoopIdle(). But proof of thread-safety is left as an exercise for the reader.

   Also, if you override eventLoopIdle(), be sure you call back to the base class or call Display.sleep(). Unless, of course, you like burning up your processor whilst doing nothing.

There you go - with just a bit of hackery, you should be able to move your RCP application over to Eclipse 3.3 and still get all the same UI at application startup time.

We're very excited about the next version of TFS, as it includes several big performance enhancements, as well as some interesting new features such as support for working offline. My coworker, Ben Pryor has written significantly about using Teamprise with Visual Studio 2008, which is very helpful if you're curious.

Teamprise is exhibiting at Microsoft TechEd 2007 this week. Come visit us at booth 1333 and say hello. We'd love to talk to you about what we're doing with Visual Studio 2008.

While preparing this second blog entry, I started staring at a folder full of a few dozen screen captures highlighting various features of Eclipse's Synchronize View. A few dozen is a lot of screenshots to post, but because the Synchronize view's big advantage is that it's so visual, it's hard to decide which visuals to cut out. And being a rather verbose guy^[1], it's rather hard for me to edit.

So instead of unleashing a dozen screenshots on you in a long, rambling blog entry, I decided to do one better: make a screencast of Synchronize in action. This way I can still be long and rambling, but there's just one square of visual content on your screen instead of a few dozen.

If you look back through my posts, you'll notice that I don't have any screencasts online. This is because I've never made one before. In fact, I have absolutely no experience with video editing, nor audio editing, and when put in front of a microphone, I can barely manage to speak in full sentences.

Still, the entire concept seems pretty easy. I click around on a screen while I talk. I click around on a screen all day. I also talk all day. Combining these things shouldn't be too hard, right?

But pride goeth before the fall.

It started out well: I grabbed Snapz Pro to record with. It works exactly as advertised, recording your screen (or a subset thereof, in my case just my Eclipse window) as well as audio from an arbitrary source (my microphone.)

After that, all that was needed was some editing to remove my stammering, my "um"s and "duhhh"s, my false starts, etc. No problem right? My Mac came with iMovie HD, which is supposed to be "the fastest and easiest way to turn home movies into dazzling Hollywood-style hits." Surely, this amazing program will let me splice up this silly 800x600 video trivially, right?

To be fair, iMovie does seem really easy to use. Slow, but easy. After only a few clicks (and thirty minutes of it grinding away), I'd imported my screencast and split the audio and video tracks so I could see the waveforms easily and know right where I wanted to splice, which is also very easy.

Unfortunately, iMovie 6 does have a minor issue with stability. And by "minor issue," I mean it has a tendency to crash every 10 minutes. Knowing this, one might suggest I go find a new piece of software to do my video editing. But I'm the dreaded combination of lazy, cheap and stubborn, and thus came up with an ingenious workaround to continue using the free iMovie that I had already mostly learned: have a beer or two before using it (to remain calm enough to keep myself from stepping on my computer) and saving often. No problem, right?

Right.

Despite being slowed down by the constant crashes, I got about halfway through the process of making me sound like a human before iMovie - predictably - crashed for approximately the 714th time. But this time, it took my entire project file with it - somehow in that crash it had become corrupt. I googled for solutions, I tried various things to recover it, I checked permissions, I made a sacrifice to the software gods... I even rebooted. No love: iMovie continued to tell me it couldn't be read.

At that point, I just walked away, too frustrated with the process to even continue. I haven't touched it since, and given this delay, I thought I owed my one reader (who is, admittedly, probably Google's indexing bot) an apology. I will actually finish this article on Synchronize. I promise. It will probably consist of a few dozen screenshots, and I'll hate myself for doing that and curse at it every time I see it. But at least I'll be done with it.

I suppose I could attempt to finish this stupid screencast, but then I'd have to decide whether I want to suffer through using iMovie or if I should just buy Final Cut Pro. That is to say: being cheap, I need to determine if Final Cut Pro is less expensive than the quantity of oxycontin I'd need to take to be able to handle using iMovie or not[3]. (Beer just isn't going to cut it anymore.)

(If you're wondering, of course that oxycontin comment is a joke. I would never buy oxycontin. I'm way too cheap for that.)

1. Perhaps you've noticed, as even my footnotes get footnotes^[2].
2. Often very similar to this one.