Submitting to the Black Hole

There’s a Web site that reports how long science-fiction authors have had to wait for responses from various publishers. It’s called “Submitting to the Black Hole“.

Some people had to wait more than a year just to get a response. And some are still waiting.


Then again, some got a response in a matter of weeks, or even days (though the averages aren’t usually quite that good). So if/when I’m ready to submit something new for publication, I think I’ll be spending some quality time with this list.

Embedding WinForms controls in IE

I’ve had to dig this up several times before, so it’s about time I blogged it.

You can embed a .NET WinForms control directly into a Web page, much like a Java applet or an ActiveX control. It only works in IE, but unlike ActiveX, there’s no security prompt and nothing to install. (Obviously, it runs in a sandbox, so it can’t access your hard drive or anything.) You also have to be careful about what events you hook and suchlike; the security model is pretty restrictive (I’ve blogged about this before).

Anyway, here’s how to embed a UserControl into Internet Explorer.


My first go-round, I got frustrated with the amount of duplicate code I had to write in my ANTLR grammar just to build real parse trees. ANTLR is great if you want to parse and evaluate an expression, but it kind of sucks if you want to parse and understand source code.

So I wrote a meta-parser and had another go of it. I’ve now got a Ruby script that reads in my metagrammar, does some chugging, and spits out an ANTLR .g syntax file, as well as some autogenerated .cs files. (All automated as part of every build, of course.)

Here’s the cool stuff my metaparser can do.

  • Node classes. Just about every parser rule now has a corresponding class, which is automatically codegenned by the metagrammar script. That class has properties for each of the syntax elements, so for example, when the Parameter class is automatically generated, it is given these properties:
    • public TokenNode Semicolon { get … }
    • public TokenNode Style { get … } // var, const, out, or nothing
    • public List<IdentItem> Names { get … }
    • public TokenNode Colon { get … }
    • public INode Type { get … }
    • public TokenNode Equal { get … }
    • public INode Default { get … }
  • Readability. In the metagrammar file, token names are in angle brackets, such as <Ident>. Parser names, like MethodCall, aren’t in brackets. Everything is Pascal-cased. I find this far easier to read than the capitalization-based TOKEN and parserule convention used by ANTLR.
  • ANTLR bug workaround. Since ANTLR sometimes forgets that EOF is a valid end-of-rule token, my metagrammar script automatically generates the appropriate workaround for every rule in the metagrammar. Suddenly I can write unit tests for everything again, without even having to think about it! Hooray!
  • Remove duplication. To get keywords and semikeywords to work, I had to list them all twice: once in the tokens{} section, and again in the keyword and semikeyword parser rules. (Predictably, when I went to remove the duplication, I found that I had made some mistakes: the two lists weren’t exactly the same.) The metagrammar just lists them once, and it automatically generates the necessary duplication to make ANTLR do the right thing.

Honestly, though, I think that the class-for-each-node-type thing is going to be the coolest. Especially when I want to start hanging some hand-coded properties (like a List<string> of all the used units, so I don’t always have to walk the Ident nodes) off of some node types. (Partial classes are going to be so sweet for this.)

The only downside is that I more or less had to start over. I’ve still got parsing for over half the rules, but I threw away my old tree construction and started over, so I’m only finished with 42% of all the rules. But the parse trees are going to be way cooler now that I’m doing them myself and not worrying about ANTLR’s AST.

(And no, I still can’t release the code. Working on that.)

Paid-off count: 10

Paid off GSB this morning. We’ve been planning it since we made the budget late last month. Our second-draft budget was tantalizingly close, and we decided to stretch and skim and make it work. Tightened the grocery budget, put off a couple things, and go.

I’m glad we did. That receipt with “Balance Due: 0” really makes me happy. Another one bites the dust.

Pimp your IDE: Visual Studio Hacks

Pimp your IDE - Visual Studio HacksMy new favorite book: “Visual Studio Hacks” by James Avery, published by O’Reilly.

If you use Visual Studio, you need this book. You will learn things you didn’t know you needed to know. Many things.

My personal favorite hacks:

  • Hack #10: Add Guidelines to the Text Editor. Delphi’s 80-column-margin line comes to Visual Studio — just a vertical line at the 80-column (or whatever) mark, that you can follow or ignore. Very helpful when you want some consistency to your code layout, so you can actually read your code from different computers with different screen sizes and IDE settings. You can even customize the colors and set multiple guidelines.
    • Bonus tip: Try adding negative numbers for guideline locations. We amused the whole department for about fifteen minutes with this one.
  • Hack #17: Find Files Quickly. This describes VSFileFinder, a free add-in that lets you type a file’s name (or some subset of its name — incremental substring search, how cool is that?) and immediately open that file with one click, without needing to hunt through Solution Explorer to find the right project and directory. Just the filename. From a docking window, so you don’t even have to open a modal dialog. Our app has 30 different projects, so this add-in is a godsend.
  • Hack #34: Customize Your Project Build Process, subsection: Canceling a failed build. If you have a solution with two projects, and B depends on A, and A fails to build, Visual Studio will, by default, go ahead and compile B anyway (no, they didn’t fix this in VS 2005), even though there’s no possible way you could get anything but stupid error messages (remember, A didn’t build, so B is missing a dependency). What’s worse, it shows B’s errors first in the Task List, thus making it nearly impossible for you to find the error that you actually need to fix. This hack shows you how to write a macro that will actually stop your build as soon as it fails. Fantastic. Visual Studio finally achieves the same level of sophistication as make.
  • Hack #44: Speed Up Visual Studio, subsection: Turn Off Dynamic Help. ‘Nuff said.
  • Hack #77: Master the Visual Studio Command Prompt, subsection: Add the Visual Studio Command Prompt to the Explorer. Right-click on a folder and select “Visual Studio Command Prompt Here”. A must if you ever use the command-line tools from the .NET SDK.
  • Hack #95: View an Outline of Your Controls. Delphi’s Structure Pane comes to Visual Studio.

There are others that might become my favorites once I try them, like #47 (Build a Custom Tool — looks like it could be cool for doing codegen) and #89 (Writing a Visual Studio Add-In), and I’m sure there are plenty that would be fabulous if I cared (like the Web Services power-user stuff). And the Reflector IDE add-in looks like it would be spectacular if the download wasn’t a broken link. But all in all, this book was well worth the $25 my department paid for it, especially now that we’re owned by a company that doesn’t believe in profit-sharing so it’s not even coming out of my pocket indirectly.

The only problem with this book is that our department only has one copy, so we’re always having to try to find it so we can make another PC stop building after a build failure.

Running all the unit tests from Visual Studio

A while ago, I blogged about my frustration with trying to run all the unit tests in Visual Studio. Well, here’s how you can do it. Not only can you run all the tests in your entire solution, you can do it with a single keystroke. (Which is handy, since it’s the sort of thing you do all day long.)

First, download and install TestDriven.NET. Go do it now. This thing kicks ass. You can right-click on the solution, or on a project, or even inside a method in the code editor, and say “Run Test”. It works flawlessly with NUnit test projects, and I’m told (though I haven’t bothered to try it) that it works equally well with Microsoft’s testing framework. You can even right-click inside a parameterless method that has nothing to do with any test framework, and select “Run in debugger”. I mean, how cool is that?

Okay, moving on: we want an easy way to run all the tests. How you do that depends on which edition of Visual Studio you have.

If you have full-fledged Visual Studio (not Express)

Next, you write a macro. Open the Macros IDE (Tools > Macros > Macros IDE). Double-click on MyMacros, then Module1, and type the following macro into the editor between “Public Module Module1” and “End Module”. (Yes, it’s VB. The sadists who write the Macros IDE won’t let you use anything else.)

Sub RunAllTests()
    Dim SolutionName As String
    SolutionName = System.IO.Path.GetFileNameWithoutExtension( _
    DTE.ActiveWindow.Object.GetItem(SolutionName).Select( _
End Sub

Then just close the Macros IDE, and the macro will be automatically saved. When that’s done, you can go into Tools > Options > Environment > Keyboard and bind a keystroke (I use Ctrl+Shift+T) to Macros.MyMacros.Module1.RunAllTests.

If you have Express

Visual C# Express doesn’t seem to have a Macros IDE, so you can’t run all your tests with a single keystroke. The next best thing is to run the NUnit GUI. (TestDriven.NET installs NUnit to C:\Program Files\TestDriven.NET 2.0\NUnit. You’ll want to run nunit-gui.exe.) Then you can build in Visual Studio, and Alt+Tab to NUnit and hit Alt+R to run your tests.

(Another option would be to write a Visual Studio add-in that really does let you run all the tests with a single keystroke, since add-ins do work in Express. If anyone does this, or finds an easier way to run all the unit tests in Express, let me know!)