Fugato

IE6 started to throw this JScript error in my face, “Stack overflow in line: 0″, in a mildly involved bundle of one-off Javascript I was cobbling together.

It was a series of calculations trickling down from an initial textbox change through cascading onchange events and homemade callbacks, and it worked, that’s not the problem — but once it was done this error message popped up each time. It didn’t happen during the calculations, it happened outside my code. I did not have any infinite recursion anywhere. Firefox showed no problems.

When I disabled the deepest part of the calculations (where the execution stack went deepest), this didn’t occur at the end. I could pinpoint just where I had to stop such that this wouldn’t happen at the end. This was around 10 stack frames, if I recall correctly.

Googling turned up nothing in the way of an explanation or a fix.

I finally worked around it by wrapping one call in setTimeout(function() { call(); }, 0); to put the rest of the execution on a fresh stack.

That worked around the spurious error dialog … but I still don’t know what was going wrong. Can’t stand that!

The start.com News blog announces (with a heading in all-lower-case letters; that used to be trendy):

we’re hiring developers

Want to work on one of the coolest projects at Microsoft? [...] Do you want to take ideas from concept to live on the web in just a few hours or days?

That is the latest entry on the blog. It is dated November 17 2005. Ouch.

I know, I know, priorities, cost-benefit, concentrate on features, etc. But still.

It’s 2006. Eight years of development and four major versions released. Why does a 250-billion-dollar company’s flagship development product still squeeze large, frequently used, tabular user interfaces into non-resizable dialog boxes?

Tables with tens of thousands of rows, some of them containing astounding stretches of text such as TeamFoundationContextMenus.SourceControlPendingChangesSourceFiles.Compare.TfsContextPendingCheckins.CompareWithWorkspaceVersion (honestly!) — squished in a 374×49-pixel porthole quivering in its puniness in the center of my 1920×1200-pixel screen. Who perpetrates this kind of obscenity?

In that last one, how do we tell the four different ActiveDirectory exceptions apart? Well, we can mouse over them to get a tool tip. Or we can drag the eminently draggable-looking column separator line such that the checkbox columns disappear off the right edge.

I don’t doubt that this product got usability tests up the wazoo. Some triaging group meeting must have reviewed the (surely inevitable) suggestions of resizable dialog boxes, and concluded: “nah.”

Hey, maybe in late 2008.

Fishy hang.

My Visual Studio 2005 hung completely, out of the blue. Did not respond to any mouse clicks or keyboard events, though it did redraw.

I tried firing up another VS2005 to debug it, but that hung too and then closed.

So I tried firing up a VS2003 and attaching the native debugger to the hung VS2005. And the debugger crashed.

I sent the crash data to Microsoft, and tried again; same results several times, with the crashed VS2003 restarting automatically each time.

Finally closed the VS2003 manually, started a new one and attached, successfully. By this time the VS2005 window was gone, but the process was still there. Got a minidump of the hung VS2005 if anybody wants it.

(Incidentally, one of the process modules jumped out at me with the name custsat.dll … that might stand for “customer satisfaction,” which, taken in context, is a wee bit amusing.)

Detached and killed the VS2005 process and started a new one, but nothing came of that.

Finally resorted to a reboot, but the shutdown was interrupted by a VS2005 window appearing, with a modal dialog with this message:

TF30331: Team Explorer could not connect to the Team Foundation server source
used during your last session. The server may be offline or the network is unavailable.
Contact your Team Foundation Server administrator to confirm that the server is available
on the network. Use the Connect to Team Foundation Server command on the Tools menu to
reconnect to your previous server.

The server returned the following error: The operation has timed out

Figures that it was the Team Foundation server, because the same mess was going on on a co-worker’s machine at the same time.

But … the server catches a flu and the whole IDE hangs?

Closed the modal dialog and the studio window, rebooted, and started up VS2005 again.

It seems to be working now … but I don’t need this kind of aggravation. I have work to do, and I miss my VS.Net 2003 (!) and the trusty, robust, never-hanging Subversion we were using along with it.

I googled the error message and got nothing. So if this were Eclipse or NetBeans or IntelliJ (or, indeed, Subversion) hanging, I would go file a bug and attach the minidump to it and feel all warm and fuzzy about helping out. And I would cheerfully expect a new version fixing the problem. In less than two years’ time, even.

But it is a Microsoft product; I do not know of a public bug database, and I do not feel inclined to go telephone the uninvitingly-named “Professional Support Services” and stay on hold while all of their customer representatives are currently busy assisting other callers and will answer my call in the order in which it was received, and then try to convince one of them that I’m honestly not that big an idiot (a relatively small-framed one, in fact) and that there really is a problem. No thanks. So last-millennium.

That kind of prejudice — while indicating the image Microsoft still has, despite the best efforts of MSDN bloggers — begs to be proven wrong and unfair. I want it to be proven wrong and unfair. And sure enough: after a little spelunking, here is the place to submit feedback, without hanging around on the phone at all. I’ll go do that instead of whining like a crybaby.

All right, after signing in with my Passport login, and then signing up with name and email and age and all that (yet again — now, what was Passport for, again?), I spent about 20 minutes carefully describing what happened, providing exact product and add-in versions and the like, and then submitted. Kabloom:

And yes, that does repeat when I back up and retry the bug submission several times.

Ah well. I did give it a try. And I’m glad they have it. Just look forward to trying it out when it’s feeling better.

EOR

I’m getting to like Windows PowerShell quite a lot. Specifically, I like it almost as much as I detest the smoldering pile of rank excrement it comes embedded in: that vile ol’ cmd.exe shell window.

Because cmd.exe, the perennial ball-and-chain of Windows command-line usage, still suffers — after all these years — from a host of ill-forgivable usability flaws:

• Drag-selection selects simply a rectangle of characters, instead of following the flow of text. Sometimes you want that; generally you don’t. There is no way to select text like every other text environment does (e.g. Notepad, most shell windows in Linux, etc.). Why?
• You can’t drag-resize the window horizontally! You have to open a properties dialog, select layout, and type in the new width in characters. Why?
• No keyboard shortcut for paste. Why?
• No keyboard shortcut for scrolling. You can enter a Scroll mode in which the arrow keys work. To do so, fumble for your mouse and right-click and select Scroll. In this mode, typing anything results only in a loud beep. You must press Esc to go back to typing mode — in the usability spirit of vi. Why?
• By default there is no scrollback buffer; what’s stored is simply what’s on the screen. If it’s gone off the top, it’s lost. You can set the buffer bigger than the window in Properties -> Layout, but it’s tiny by default. Windows takes up several hundred megabytes just for chugging along like the freight train it is, but here they really had to save a couple of dozen kilobytes. Why?
• To drag-select text to copy, I have to first right-click and select Mark. This is inconsistent with everything else, anywhere, and there’s no point: mouse dragging does nothing in the window otherwise, so there is no need to disambiguate drag-selection from anything. If I set “Quick-edit” mode in Properties, I can drag-select directly … but then the right-click context menu doesn’t work until I turn off Quick-edit mode. Why?

And that’s leaving out the paltry line-editing functionality and weak scripting support, as compared to Unix shells. At least Windows PowerShell does something about those.

cmd.exe is so bad that once it has broken your spirit you actually marvel at the most minuscule hints of convenience in it: “Ho! F7 triggers a pop-up window with the command history. Boy, I just can’t believe how I have been able to never see that before!”

Detecting a novel feel on the skin of his back, the slave asks his driver: “Hey, is that a new cat-o’-nine-tails? How silky smooth it is!”

It is a real shame that the very promising innovation that is Windows PowerShell has to be marred by being encased in this anachronistic usability disaster.

After a decade and then some, why must Microsoft’s only command-line console still feel like a botched freshman programming assignment?

I meant that as a rhetorical question, but here’s one possible answer:

Guy in Microsoft Command Shell Development:

The best way to scroll a console is:
Alt-Space, E, L

<ESC> or <Enter> exits this mode.

Along those same lines, a quick way to paste is:
Alt-Space, E, P

User:

! that is four (4) keys :(
i think i’ll stick with the mouse until this gets improved…

thanks anyway

cmd.exe guy:

It actually becomes ingrained quite quickly as a single action. Ask anybody who’s spent any time using Emacs or VI how quickly these things become second nature!

And here I thought I was joking that vi was cmd.exe‘s role model of acceptable usability.

Okay, I’m done; I feel better now.

Earthy green polo shirt guy

“Glass-like interface elements that you can see through.” Green is their favorite color.

Microsoft is working to put out a new version of Windows, called Vista (incidentally, the Icelandic word for “Save” in computer programs).

It probably costs millions of man-hours and billions of dollars to create.

And this “features” page is supposed to sell it to us.

It appears that Vista’s most significant feature is a trendy-grey-haired guy wearing an earthy green polo shirt and a toothy smile.

He looks friendly. I think I’ll buy it.

It will be worth it, not only for earthy-green-polo-shirt guy, but also for the “spectacular visual effects such as glass-like interface elements that you can see through.”

Whoo.

Where do you want to yawn today?

If we liken the Firefox Web Developer Extension to a Mazda RX-8, then the IE Developer Toolbar … okay, is not quite the pile of leaky garbage bags left in the parking garage by my delicatessen neighbor. It is better than that. And has more hope for advancement. But it is still vastly inferior.

I tried out the “beta refresh” of Microsoft’s developer toolbar for Internet Explorer. It seemed a big relief that, after years of excellent developer support in Firefox with the Web Developer extension, we were finally getting the same in IE.

Well, not quite.

Toolbars mixed up

The toolbar did not appear after install and reboot. “Developer Toolbar” was checked in the View→Toolbars menu, but no dice. Oddly, the MSN Search toolbar did appear, but that was not checked in the View→Toolbars menu. So I unchecked “Developer Toolbar” and checked “MSN Search Toolbar” … yep, MSN Search toolbar vanished and Developer Toolbar appeared.

Outlining broken

Works here. Does nothing on another page on same site, and plenty more pages. I have not seen a pattern to this failure yet; maybe doctypes or client scripting matter.

View Class and ID Information

… for a medium-sized form page, takes close to half a minute, during which the IE window is hourglassed and “(Not Responding)”

Show Ruler

… works sometimes, sometimes not, just like outlining. But the kicker: it has the keyboard shortcut Ctrl-R, the same one I have been using to reload the page for years. Ctrl-R now pops a ruler in my face. On some pages. Others still reload.

DOM Explorer

… works, and that’s great, but it does not show me which CSS style rules apply to a given element and where they were specified. The Firefox DOM Inspector shows that and it is in-freakin’-valuable for troubleshooting layout. [Not a bug, you say? I say it's a requirements bug!]

I’ll skip other minor quibbles, except I want to mention a time-worn classic UI gaffe in the DOM Explorer: the File menu. What file operations does the toolbar offer? Well, none. This File menu has two items, “Refresh” and “Undo all”; it is being misused as a Misc menu. Doubly silly because there is also a menu named Misc.

Seems to me that this was an alpha. I am looking forward to the beta! :-)

Bite the bullet. Get rid of both SourceSafe and web projects, in one fell swoop.

I am not the only one who dislikes Visual Studio .Net web projects and SourceSafe. I am using the term “dislike” loosely here, as one “dislikes” cranial hemorrhaging and Richard Clayderman. They are worth getting rid of, but it can be hard to bite the bullet and get it done, and the hand editing can be tedious work if you have a lot of web projects.

So I wrote a couple of utilities to make it a little easier. One, EnableWebItemsInNonWebProjects.exe, is for tweaking your Visual Studio .Net 2003 installation to support web items in non-web projects. It is an automated implementation of this method.

The other utility, MakeLifeBetter.exe (sorry for the whimsical name; these are quick hacks and my productization department is on leave), is for simultaneously converting web projects to “local” (non-web) projects and stripping away SourceSafe bindings if they are present. I find that it is advisable to make these two changes together, for two reasons:

• If you convert web projects to non-web projects while still hosting them in SourceSafe, others will experience weirdness when they “get latest” and receive your changes. [One of my biggest pet peeves with the combination of the Visual Studio .Net 2003 project system and SourceSafe is that problems never seem to be perceived clearly, they always seem to be "weirdness" or "voodoo" (of the mythical nasty variety) until you start delving under the covers. I don't like the covers, I guess.]
• If you migrate to Subversion while still using web projects, Visual Studio will have problems, because web projects are not happy about subfolders with names like .svn. Your mileage with other version control systems may vary.

So assuming you want to migrate to a proper version control system and abolish the use of web projects in your work, then this utility may be for you.

If you want to make only one of these two changes to your solution, then you’ll have to make the appropriate (fairly obvious) modifications to the source code, which is provided in the download. It is undesigned and uncommented and unglamorous; I know. Don’t bug me about it.

Now that I’m no longer subjected to SourceSafe and web projects at work, I look roughly like this. With more hair.

I recommend:

1. migrating your tree as-is to a fresh Subversion repository using vss2svn (I suggest the bugfix branch, login as guest:guest),
2. checking out a working copy from your new repository (e.g. using TortoiseSVN),
3. running this utility on it,
4. trying it out in Visual Studio, and
5. committing the changes.

I also strongly recommend just working with TortoiseSVN and not bothering with the source control functionality in Visual Studio. It may just be a matter of preference, but give it a try, at least.

Both of these utilities are command-line tools. Both print terse usage instructions when invoked without arguments.

Caveat: these are quick’n'dirty hacks. Error checking may be charitably described as “scant.” They have been tested on one (1) VS.Net installation and one (1) solution, containing twentyish web projects. They worked in these test cases. In your case, they may very well steamroll your project into the ground, bankrupt your company, poison your relationships with your loved ones, and give you cooties. Use at your own risk. Read the source code. Make sure you do not stand to lose any work if it all goes awry. Back up your VS.Net installation. Work on a pristine working copy from a reliable version control system. Diff to check that it did the right thing. Do not — do not — sue me. Always sue only those who have money, that’s where the return on investment is, and you get to feel like Robin Hood. Watch your cholesterol. Cut down on caffeine, TV, hallucinogenic drugs, and procrastinatory blog surfing. Read Chekhov. Work out. In your darkest moments, in your deepest despair and loneliness, remember that in that state your forward vision is impaired: there are better times ahead, though you cannot see them. This too shall pass.

Here is the download: IDetestWebProjectsAndSourceSafe.zip. Sorry for that name too.

Here’s one techie posting to alienate my regular readers (both of them) … I’ve encountered an apparent bug in the C# compiler in Visual Studio .Net 2003. Witness:

public interface ProductRow
{
	int Count { get ; }
	int Price { get ; }
}
public class ProductRowCollection
{
	public ProductRow this[int index]
	{
		get { return null; }
	}
	public int TotalPrice()
	{
		return ( this[0].Count * this[0].Price );
	}
}

(Yeah, I know the code is silly; I stripped it down for display purposes.)

This causes the compiler to bork with the following errors:

test.cs(14,20): error CS1513: } expected
test.cs(14,33): error CS1031: Type expected
test.cs(14,42): error CS1519: Invalid token ‘)’ in class, struct, or interface member declaration
test.cs(16,1): error CS1022: Type or namespace definition, or end-of-file expected

The first error is signalled on the reference to the Count property getter, a perfectly decent member of ProductRow. I am fairly sure the code is valid. The error seems to indicate something going awry in lexing.

It goes away if I put in a + instead of the * … maybe the compiler is confusing itself by mistaking the multiplication operator for a pointer indirection operator, for some reason? The C# language specification seems a little vague on the precedence and associativity of the pointer indirection operator; is it possible that this really is invalid code and the compiler is correctly rejecting it but just giving a shabby error message?

It also goes away if I comment it out and back in! This is really odd: I get this in Visual Studio, indicated with a red line under the Count reference, and I try to build and I get the compiler error … and then I comment the line out, then uncomment it again, and I don’t get a red line and it compiles! It makes sense that the syntax highlighting “snaps out of it” when I comment and uncomment … but the compiler too?

Of course that’s a shoddy, brittle, voodoo workaround, and sure enough, when I check it in it gets picked up by the automated build system and the same compiler error comes up there.

A sane workaround is to extract ProductRow row = this[0]; and write row.Count * row.Price … this way no error is raised. Probably judiciously applied parentheses would achieve the same.

I googled a little bit, but didn’t find anybody talking about this kind of glitch. So I hereby ceremoniously christen it The Marteinsson Mess, after my coworker who stumbled on it.

Update: this has been fixed in .Net Framework SDK v2.0 Beta 2.

After running out of batteries and being started up again, my computer just offered me this description of stuff-that-went-wrong:

When I clicked for more information on the “serious error” of batteries running out, I got this:

Now, I’m a self-proclaimed techie (despite working in Marketing), but I was afraid to click any further. If the above information is not “technical,” I’m not sure I want to know what is.

And sure, I did click further. That gave me a couple of files. They were technical information, fair enough. But that stuff in the dialog box? What is that, the layman’s explanation?