For some strange reason, I still get surprised at how bad Microsoft is at designing user-interfaces. And now I'm not even talking about the graphical ones. The command-line has long been viewed at Microsoft as something inherently evil: everything must have a graphical interface to be deemed usable; command-line tools are by definition user-hostile. Which, of course, is not true. Badly designed command-line tools are user-hostile, just as badly designed graphical user-interfaces are user-hostile. And Microsoft is pretty good at doing both.
Microsoft does not lack good interface designers. Where they really put in the effort, the result is sometimes really good. For example, I like the new Office-toolbar and the interactive display of keyboard shortcuts (even if it's a little annoying to have to relearn the entire user-interface. Every single command seems to have been moved), and the new dialogs with big descriptive buttons instead of just yes/no buttons. Also, I like the new Google Chrome. No wait, wrong company.
But the command-line tools seldom get any attention (with the possible exception of PowerShell, which I haven't tried yet). When will we get a new Windows console, for example? With a real font selection dialog, proper resizing, etc.?
The tool which actually caused my bloodpressure to exceed the "must-blog-about-it" point, is CACLS. CACLS is a tool for displaying or modifying the ACLs for files and folders. I wanted to use it to be able to remove a write-protected file (a file checked out by svn with the svn:needs-lock attribute), and I wanted to do it in an automated test.
Guess what: CACLS will ask the user for confirmation when changing permissions, and there is no option to turn it off. What is the BLOODY POINT of having a command-line tool which cannot be used from a script or bat file? The workaround is apparently to do "echo Y | cacls ...", but still. How hard can it be to add a single flag to switch on/off the question?
Now I'll go back to work and try to figure out how to prevent interactive dialogs blocking my automated build.
2 comments:
Hi,
I'm new to you blog. I was looking for answers as to why MFC sucks. Needless to say I didn't find any.
I don't want to just complain, but really...
I find that any time I need to use MFC, I am confronted with the same old crap. The obviously standard thing I want to do is just not supported. I mean... did these guys ever actually try creating an app using their junk? I doubt it.
I'm going to set aside the entire command line issue, because frankly it would take too much time to get into. So let's just focus on the GUI deficiencies.
We all run our computers at the same monitor resolution, right? So what's the problem... You don't??? Well for luddites like you we should be able to resize a dialog, right? Not if you are using MFC! No all the controls must be placed in a specific location. God forbid there is an intelligent resizing method. No... You have to create a frame window, and figure out how to wire it into a dialog yourself. QT at least makes an attempt to provide the feature.
My 15 year old daughter told me, after listening to me "rant" a bit, "maybe that's why they call them tools". It made me laugh, and I thought I'd pass it on...
I wrote a blog post about this problem, actually.
Post a Comment