After I installed Visual Studio 2010 beta 2 (hot off the presses) in a VMWare virtual machine (you don't think I'd be crazy enough to install it on my real machine did you?) I noticed some serious performance problems with the text editor. It was very laggy - couldn't keep up with my typing - and had some visual glitchiness.
I've seen similar problems with WPF apps (including our own, running in VMs before) so I had a sneaking suspicion what a solution might be. I tried my stock fix, and sure enough the editor became right snappy.
The fix (well known by some, I'm sure) is to disable hardware acceleration by creating the following DWORD registry value:
and setting it to 1, as described here. Restart Visual Studio (doesn't even require a reboot) and you should be good to go.
From time to time I find myself faced with a really annoying problem - a Windows application that has positioned itself offscreen. This usually happens for one of two reasons:
- A bug in the software. Sometimes things go terribly wrong, and the application, for lack of a better phrase, flips out. I just had this happen last week with Firefox - it would end up above and to the left of my screen (might have been a script or add-in, I'm not sure). Another common cause is an application that writes bogus data when trying to remember its screen position for the next time it's launched. Close it and relaunch, and bang, it's off-screen.
- Remote Desktop'ing into my multi-monitor desktop from my laptop. In that case, everything that was on the second monitor suddenly becomes off screen, and I need to move it back to the primary monitor in order to interact with it.
Now, Windows does provide a way to deal with this problem - by right-clicking on the item in the task bar, selecting Move, and using the keyboard (nicely described here). It works, but I always find it to be clunky and a bit flaky (sometimes it take a lot of keyboarding in just the right way to get the app to pop on screen). So I took a couple of hours and hacked together my own solution to the problem - a utility called "Front and Center!"
You can see a screen shot of the app here (I tried to embed the image in this post, but for some reason its not working, not sure why).
Hopefully it's pretty apparent what's going on. The app enumerates all the top level windows and lists those that are offscreen, along with their coordinates and size. Highlight it and click "Front and Center!" and it will move the app to your primary monitor.
The app requires at least the .NET Framework 2.0 be installed. The app itself requires no installation - just unzip and run.
I hacked this together pretty quick, so I'm sure it has problems. I've only tested with my standard ("center and right") dual monitor setup on Vista - I may very well have done something dumb that causes problems for other configs. Drop me a line if you have problems or ideas for improvement.
You can download it here.
The inimitable Jeff Atwood of Coding Horror fame (or is it Stack Overflow fame now?) recently blogged about the importance of typing skills for developers. In typical smackdown style, he posited that "coding is just typing". Jimmy Bogard disagreed, saying that the number of lines of code typed per day is actually quite small, and the productivity difference for typing that much code is quite negligable.
I happen to agree with both of them. What neither discussed is that as a developer, I type a hell of a lot more than just code. I type emails. I type Word documents. I submit questions to Stack Overflow. I type search terms into Google and URLs into the browser. I Twitter. My ability to do all of those things efficiently is affected by how well I type, and all of those things are critically important to doing my job. So while typing fast may not be hugely important for being a coder, it is hugely important for being a developer. I type all damn day, whether or not I'm coding that day.
There's another important point that I think needs to be stressed - good typing technique can help avoid repetitive stress injuries. I'm pretty convinced that my lack of RSI problems is at least in part due to good typing technique imparted by my 7th grade typing teacher. Whenever I feel a glimmer of discomfort in my hands, I can almost always attribute it to either a) too much mousing (know thy keyboard shortcuts) or b) falling back into sloppy typing technique (my great failing is one-handed modifier action - e.g. ctrl-w with one hand instead of two). Over the years I've known people that literally could not work at a computer any more due to RSI problems. Now if THAT isn't a terrifying thought that keeps your hands glued to your home keys...
In an effort to plumb the outermost depths of blogging lameness, I'm writing today to announce my participation in a podcast about software development. Why is that lame? Because the podcast started over two months ago. Yes, that's right, I can't even be bothered to pimp my own stuff. Like I said, lame.
The podcast consists of Jon Galloway, Scott Koon (aka Lazycoder), K Scott Allen (aka OdeToCode), and little old me talking roundtable style about whatever software development related topic tickles our fancy that week. Come on over and give us a listen.
I want to give a shoutout to my wife Kathi for coming up with the name. We'd toyed around with several other names, most of them profoundly lame. We were about to pull the trigger on the least lame name (which was still pretty lame) when she rode in on her white horse and saved us from ourselves by coming up with Herding Code (and 3 others which were all better than any of our options, but HC was a clear winner). If you need a kick-ass web designer, look her up. No, she didn't design the Herding Code web site...she's too busy doing real work.
Scott Hanselman tweeted a link to Daniel Cazzulino's blog post about automatically synchronizing the Visual Studio Solution Explorer with the active item open in the editor. It's a great tip, but I personally have never been a fan of the Track Active Item option - I find that it slows down the IDE, causes distracting visuals, and often just isn't the behavior I want. I do, however, often want a way to manually sync up the Solution Explorer with my currently open item.
Fortunately, it's very easy to accomplish this with a very simple macro. The idea is very simple - just turn on the Track Active Item option that Daniel mentions, and turn it off again. It's a two-liner:
You can wire up that macro to a toolbar button and/or a keyboard hotkey, and (as ScottHa would say) bam, you're golden.
Sadly, it appears the answer is "yes". Specifically, the debugger has a huge limitation - one that's been there since Visual Studio 2005 (maybe even 2003). You can't set a breakpoint on the first line of an anonymous function. Consider, for example, the following:
2: function aFunc()
7: var aFunc2 = function()
9: alert("hi, yourself");
10: alert("what's your problem?");
Here aFunc is a named function, and aFunc2 is a variable that points to an anonymous function. With the Visual Studio debugger, you can set a breakpoint on line 4, and line 10, but not line 9.
Now, when I characterized the problem as being related to anonymous functions, that isn't quite right. In the above code, even if you give the aFunc2 function a name - "var aFunct2 = function theFunc()..."- the problem remains. There's a brief discussion of this issue on the ASP.NET forums here (note the date - March 2007), but the explanation rather nebulous. Whatever the root cause, it's a horrible limitation that I'm stunned wasn't addressed for RTM.
Guess it's back to Firebug for me. Or maybe it's time for another look at Aptana.
I finally got around to installing the latest beta of Windows Live Writer, my favorite blogging tool. As part of the install, it displays the following dialog:
I can't believe that in this day and age, applications still want to change my home page. The checkbox was checked by default, by the way - I unchecked it before I took the screenshot.
A while back I blogged about a problem I had installing Visual Studio 2005 on a fresh Vista install - it complained about requiring Windows XP SP2. I never found a satisfactory explanation, but copying the DVD contents to the hard drive worked around the problem. The stock suggestion was to check the Compatibility settings on the property page for setup.exe - but in my case no compatibility mode was set. Or was it?
Recently I tried installing Visual Studio 2008, and got the same error. Following a suggestion from the MSDN forums, I checked the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers. Lo and behold, it contained an entry for %tempdir%\setup.exe. But I'm not running setup.exe from the temp dir, I'm running it from the DVD, so that entry shouldn't affect anything, right? Wrong. When you run the installer from the DVD, it appears to copy itself to the the temp dir and run itself from there. At that point, the compatibility flag is in effect.
Where did the registry setting come from in the first place? I have no idea. But removing it allows the Visual Studio install to proceed.
Maybe this is common knowledge, but my co-worker and I spent some time chasing this down today, so I figured I'd post it in the hope that it will save other people some time.
Normally, a empty, unstyled DIV reserves no space in an HTML document. However, it seems that under Internet Explorer (we were testing under IE7), if you set the innerHTML property of such a div to an empty string, suddenly the DIV starts taking up space. In other words, if you have this:
<div id = "theDiv"></div>
some more text
and execute a line of script that does this:
document.getElementById("theDiv").innerHTML = "";
then suddenly a blank line will start appearing in between "some text" and "some more text" - the DIV now occupies space in the flow. This doesn't happen in Firefox, and I believe it's a bug in IE.
We were seeing this using ASP.NET AJAX. We have multiple UpdatePanels on a page, and one of them was rendering empty content. After an async postback, a blank line started appearing where the empty UpdatePanel was. The UpdatePanel script code sets the innerHTML property to the result of the async-postback (blank in this case), and suddenly the UpdatePanel DIV was taking up space where it hadn't before.
The fix in our case was easy - set the RenderMode property of the UpdatePanel to "Inline".
I recently blogged about the NoSquint Firefox extension, for remembering per-site text zoom levels. I also recently blogged about the Keyconfig extension, which allows you to change hotkey bindings. I guess you could say that this post is the bastard child of those two posts.
The one feature I've been wanting from NoSquint is a keyboard hotkey that jumps the zoom level straight to 100%. I keep my default zoom level at 160%, but many sites just don't render well at that level. A few are downright unusable. I can hit Ctrl-dash a few times to dial down the zoom on those sites, but I really wanted a way to easily jump right to 100% (the standard Ctrl-0 Firefox hotkey jumps to the default zoom, not to 100%, when running NoSquint). I submitted an enhancement request to the extensions author, but this morning I realized that I could probably just add the hotkey myself. I was browsing the NoSquint source when I struck on the idea to use Keyconfig to create the binding, rather than mess around with unpacking, changing, and repackaging the source JAR file.
Here's how you do it. Bring up the Keyconfig configuration UI (Tools/KeyConfig). Click the "Add a new key" button. Give the hotkey a name (I used "Zoom to 100%"), and in the big textbox enter:
Save the hotkey definition, and bind it to the hotkey of your choice (I used Ctrl-Alt-0).
That's it. Now when I hit Ctrl-Alt-0, my zoom level jumps right to 100%. Perfecto.
UPDATE - the original version of the hotkey code didn't remember the 100% setting. I've updated it so it does.
More Posts Next page »