Fugato

A brief feature comparison: in mid-flight I am impertinent enough to want to diff my checked-out code to see the changes I have made.

Under (the free-of-charge and open-source) Subversion, that would have been “Sure, here you go.”

Under (the $3,000 proprietary) Team Foundation Server, it is “be thankful I’m letting you work at all. And when you get online, go download a separate utility and ask it politely to sort out which files you have changed.”

And here I was trying to break the rant habit. Dagnabbit!

Suddenly my MSBuild fails because somebody deleted Reference.cs and there’s only a Reference.map in the Web References\LT folder.

So I try changing the reference’s URL Behavior from Dynamic to Static (just to make any change, to see if Visual Studio regenerates Reference.cs). That yields the error dialog pictured here.

Pop quiz, hotshot: what is the difference between OK and Cancel in this dialog?

None, apparently. I click OK and the property does change to Static. When I repeat the experiment, this time clicking Cancel, the property also changes to Static. Don’t know what else might be happening behind this error dialog …

… and that’s exactly the point. Where, pray tell, should I go to troubleshoot this error?

Well, silly, I’m a tech guy. I should figure it out for myself, rather than expect my tools to make it easy to find. Which brings me to my next question …

… how much did we pay for this IDE again?

I reported the Winforms Designer issue as a bug on Microsoft Connect. They swiftly marked it resolved “by design.”

What’s by design, exactly? Here are the actual and expected results from my bug report:

Actual Results

A dialog box saying “Specified cast is not valid” with an OK button, displayed three times, and then information lost about control instances within the form.

Expected Results

A clear, specific indication of the invalid typecast problem encountered while saving the form. And minimal information loss when the form is saved anyway.

So it is “by design” that instead of a clear, specific indication of the problem, we get a dialog box with only the exception message, and not even a mention that this message is coming from our own code? Just a quick and cheap MessageBox.Show(ex.Message) and their work is done?

Here is Microsoft’s exact response:

I’m afraid this is largely a byproduct of the way in which the windows forms designer works. It is setting the properties on a live object. If this object throws an exception, the designer has the choice of either letting the object throw (which would crash Visual Studio) or catching the exception. When it catches the exception, it displays the Message from the exception. The message you’re describing is the typical one for invalid cast. Hooking up a debugger will find what line the exception happens on, which would make it easy to see what the exact issue is (not just type information, but values, state, etc.)

UIFX Team

This misses the point completely.

I know full well that the designer works on live objects, and that bugs in controls therefore must cause problems. My complaint is about how those problems are handled, not that they come up. What’s “by design” is that they come up, sure. How they are handled is not “by design” (we should hope!) — it is a real usability issue that remains to be resolved. But Microsoft just shrugs it off, “you can attach a debugger to help find it.”

My point is that the exception they catch contains valuable information about the problem (the stack trace), and they do not give it to us.

Should we be grateful that at least we get a line number on compiler errors, without having to attach a debugger?

This product desperately needs competition.

Eerie. This designer thing seems to know when I’m under schedule pressure and pull out all its tricks.

Now I get “Error HRESULT E_FAIL has been returned from a call to a COM component.”

Never seen this before, don’t know what it means, don’t know what caused it, and don’t know how to find out.

Yes, my changes were lost.
No, I couldn’t repeat it by making (what I believe to be) the same changes again.
Yes, I’m happy about being able to make the changes after all.
No, I’m not happy about having no idea when this will happen again, or whether it might happen at runtime.

Let’s say you have a UserControl with a property like this:

public double DoubleValue
{
    get { return (double)NestedControl.EditValue; }
    set { Control.EditValue = value; }
}

where NestedControl.EditValue is of type object. Yeah, that’s careless handling of a possible typecast. But c’est la vie, sometimes that’s what you have, and you don’t know it, and that control is used in somebody else’s form that you’ve never seen before, and you are editing that form with the Windows Forms designer.

The designer will work merrily until you close it and say “yes, save for me please.” At this point it will present you with a dialog box saying simply “Specified cast is not valid” and inviting you to misrepresent your feelings by clicking “OK.”

When you do, it will give you the same dialog box again. You will click “OK” again, even less truthfully. And you will get that dialog box once again.

After the third time, tender mercies: the designer lets you off the hook and closes, saving your form. Phew, you think, maybe that wasn’t so bad. That’s until you discover that the designer has thrown out all the information associated with the problematic control instance, its name, text, tooltip text, sizing information, everything.

When you set out to find the cause of the problem, what do you have to go on? “Specified cast is not valid.” And which control instances got messed up. There may be dozens of them, with dozens of properties each. Happy hunting.

The lesson: when I write a tool for developers, and do it under a schedule crunch, and write a catch-all handler to display unanticipated errors … I pledge to include whatever specific contextual information I can. At least the exception stack trace. Surely that’s the least I could do.

Microsoft has posted a splash screen spec for the Orcas version of Visual Studio, asking for our impressions.

And here I was determined to start taking a more positive tack in my tech blog. Dear me.

My impressions are as follows:

The triviality

They wrote a nine-page specification complete with “Microsoft Corporation Technical Documentation License Agreement (Standard)” and stamp of approval from Microsoft Law And Corporate Affairs and table of contents and overview and context and definitions and appeal-to-stereotype Elvis arguments …

… for a drop-shadow and rounded corners and no other changes?

And thought it would be a good idea to post it publicly?

The specious claims

“[the splash screen] is no less critical than any other part of the Visual Studio User Experience.”

They lost me right there on the front page. Let me rephrase this statement while retaining the precise meaning:

“There is no part of the Visual Studio User Experience that is more critical than the splash screen.”

Gee, I could have sworn there were a couple.

We don’t even interact with this thing. It’s not a User Experience, it’s a Viewer Experience. And that’s if we even bother to View it, instead of fetching a cup of coffee while Visual Studio loads, or starting it with /nosplash.

How could it possibly be as critical as any other part of the User Experience?

This is the kind of text that comes out when you are thinking “what would sound impressive here?” instead of “what’s the plain and useful truth here?”

“The Splash Screen typifies some of the worst aspects of the Visual Studio User Experience.”

No no no. The worst aspects of said User Experience are, unsurprisingly, things we Use. Such as:

• tiny fixed-size dialog boxes around huge tabular data.
• A source control client that blocks the entire IDE while waiting for the server, and hangs on Cancel.
• A source control system that takes 38 blocking seconds to rename a file.
• A GUI designer that chokes on buggy nested controls with cryptic error messages.

It’s OK to exaggerate the importance of your work in order to motivate yourself. But don’t go overboard.

The singularly clueless marketing stereotype banter

When Elvis first heard about Visual Studio Orcas being released, he wasn’t convinced that it was worth upgrading to, especially since he felt as though he had just purchased a copy of Visual Studio 2005.

So, like any frugal developer, Elvis went and downloaded a trial copy of Orcas to test drive.

Elvis could see that Visual Studio Orcas was new and different from the moment he started the application. The changes in the Splash Screen suggested to him immediately that this release was, indeed, different.

Well, wasn’t that a nice story.

Really, this Mort-and-Elvis stuff has to go. It pains me to see dinky little stories of these contrived stereotypes masquerading as product marketing wisdom.

The inattention

Chapter 6, “Feature Decisions / Q&A” is not just blank; it consists entirely of the placeholder text from the document template: “Include a quick description [...] describe decisions and rationale here [...] We will do so and so”

This is the document equivalent of:

/// <summary>
/// Insert summary description here
/// </summary>
public class Class1
{
    /// <summary>
    /// Construct a new Class1 instance.
    /// </summary>
    public Class1()
    {
        // Add initialization code here
    }
}

Do we post this kind of code for public review? For private review? Do we even check it in?

The implied background

One can’t help wondering whether this spec gives a glimpse of some contorted in-house dynamic, where people have to participate in a ritual Product Marketing dance by writing a Mort or Elvis “scenario” for every feature spec, and inflating the importance of their work with baseless hyperbole.

It sounds like the FeatureSpec.dot document template contained the placeholder text “Insert scenario involving Mort and Elvis here,” as a hoop for each feature spec writer to jump through.

It may not really be that way, but we’re talking impressions here.

Summary

Why did nobody’s nonsense detector go wild and prevent this embarrassment from publication? The splash screen improvements themselves are nice and understated, and should have been put in place without a word.

Yeah, Team Foundation again.

When we started using Subversion at work (AnkhSVN in alpha and no VisualSVN yet), I managed Subversion adds and commits and updates manually using the excellent TortoiseSVN, and left Visual Studio out of it.

The downside of that was moving and renaming files. Doing it in Visual Studio left Subversion unaware of the change, and doing it in Subversion left Visual Studio unaware of the change. Either way, one of them ended up seeing one file missing, and another file popping up that they knew nothing about.

Generally I renamed in Subversion and then manually edited the .csproj project file accordingly. Not everybody is happy doing that, and if you happen to do it when Visual Studio has unsaved changes to the project file, then it gets a little messy.

So moving to Team Foundation (and hence SCM integration) should have made file renames less painful.

Indeed, renaming a file is now a single operation in Solution Explorer. But it takes a full minute.

I’m not pulling that number out of anywhere dark and unhygienic. I measured just now. 78 seconds.

78 seconds renaming a file!

Okay, two files. It’s a workflow class file with a .Designer.cs sidecar file. But still. Renaming one file took 38 seconds, measured just now.

38 seconds renaming a file!

And these are files that haven’t even been checked in yet. They’ve just been added. And it’s not auto-updating references to the class name in my solution, because there aren’t any.

It’s like that every time, even late at night when I’m alone in the building. It’s not because of load. Team Foundation is set up on a virtual machine in one of my company’s VMware container machines a dedicated monster machine with 6 CPUs and silly amounts of RAM, serving maybe 60 or so developers. Our Subversion server was a wee VMware machine also running Trac and some other stuff, and was plenty fast enough (but to be fair, it was only serving about 15 people). Our admins assure us that the machine is not overloaded. If it’s a matter of “killing it with iron,” then TF sure needs a heck of a lot of iron.

The clincher: it took me less time to do the rename manually (flipping out to Explorer, renaming in TortoiseSVN, editing the project file in a text editor, reloading the project in Visual Studio) than it now takes Visual Studio to do the rename automatically.

And, of course, Visual Studio is completely locked up during the operation, so my work gets to wait. Because, you know, background operations are just too much to ask.

OK, I feel better now. Just had to vent. Sorry.

… are over, because we moved our source code to Team Foundation.

Yea, verily I say unto thee, that is a modal dialog box.

So my Visual Studio is locked up — completely — until somebody gives the server the kick it deserves.

I did try clicking cancel — but, of course, the cancel operation hangs too.

This costs thousands of dollars. Thousands! The usability is less grievous than SourceSafe (and that’s not saying much) — but the reliability, at least in my experience here, is worse. Fancy that.

I miss my Subversion.

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.