May, 2012

I love using the Preview Pane in Windows Explorer to quickly preview file contents:

Usually, to enable this preview for a file extension I just open regedit, go to HKEY_CLASSES_ROOT –> .xxx (where xxx is the extension you’re interested in), and add a string key called PerceivedType with value of “text”: http://blog.wpfwonderland.com/2011/01/15/customize-windows-7-preview-pane-for-xaml-files/

However for some reason it didn’t work for .vb files. After some web searching, one solution I found that worked for me is to add the preview handler GUID explicitly under a “shellex” key: http://www.howtogeek.com/howto/windows-vista/make-windows-vista-explorer-preview-pane-work-for-more-file-types/

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\.vb\shellex\{8895b1c6-b41f-4c1c-a562-0d564250836f}]
@="{1531d583-8375-4d3f-b5fb-d23bbd169f22}"

Update: in the original version of this post I’ve jumped to an incorrect conclusion that the timer resolution depends on the operating system. However thanks to a comment from James Manning who has corrected me, I realized that this is likely not related to the OS version (because we’re seeing high resolution DateTime on both Win7 and Windows Server 2008 R2).

I’ve just discovered an interesting thing: apparently one of my machines has timer resolution 1 millisecond or better (as opposed to the typical 15ms that I’m used to seeing elsewhere).

I ran these tests on one machine:

        var dt1 = DateTime.UtcNow;
        Thread.Sleep(11);
        var dt2 = DateTime.UtcNow;
        Console.WriteLine(dt2 - dt1);

It outputs 00:00:00.0156006 (common knowledge – 15-16 milliseconds)

However on my other machine, it outputs: 00:00:00.0110011

Also, I ran this test:

        var sw = Stopwatch.StartNew();
        var start = DateTime.UtcNow;
        int changes = 0;
        int idle = 0;
        while (sw.ElapsedMilliseconds < 50)
        {
            var now = DateTime.UtcNow;
            if (now != start)
            {
                start = now;
                changes++;
            }
            else
            {
                idle++;
            }
        }
 
        var elapsed = sw.Elapsed.ToString();
        Console.WriteLine(elapsed);
        Console.WriteLine(changes);
        Console.WriteLine(idle);

and it printed:

00:00:00.0500000
3
449714

Which means it only updated 3 times within a 50 millisecond interval. On my new machine, this program printed:

00:00:00.0500001
50
471655

Which means that it updated at least every millisecond.

I was looking for error code –2146232797 (hex 0x80131623, which turned out to be what is thrown by Environment.FailFast) and I’ve stumbled upon this treasure:

http://blogs.msdn.com/b/eldar/archive/2007/04/03/a-lot-of-hresult-codes.aspx

Also, here’s a great blog about deciphering an HRESULT:

http://blogs.msdn.com/b/heaths/archive/2005/07/21/441391.aspx

I sincerely wish you to never ever need this knowledge...

Josh Marinacci (from http://joshondesign.com) recently sparked a discussion about structured editing: http://joshondesign.com/2012/03/14/sacred-cows-2

Jonathan Edwards has also blogged about this: http://alarmingdevelopment.org/?p=680#comment-59782

It seems like there is continuous interest in structured editing.

Jake Brownson had an idea to create a Google Group for us, structured editing and languages enthusiasts, and here it is:

https://groups.google.com/forum/#!forum/augmented-programming

The name “Augmented Programming” is neutral and temporary on purpose (to avoid preconceptions).

I don’t know how much participation we’ll have, but it’s good to at least have a single central forum with the right folks involved. If you’re interested in structured editing, join in!