Mon, 19 Oct 2009 23:57:00 GMT
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.
Fri, 21 Nov 2008 20:07:00 GMT
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:
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.
Wed, 19 Nov 2008 22:38:00 GMT
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...
Wed, 20 Aug 2008 03:11:00 GMT
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.
Wed, 30 Apr 2008 22:12:00 GMT
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.
Wed, 28 Nov 2007 05:55:34 GMT
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:
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.
Tue, 21 Aug 2007 21:23:00 GMT
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.
Fri, 10 Aug 2007 04:56:00 GMT
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.
Fri, 29 Jun 2007 21:18:00 GMT
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:
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".
Mon, 23 Apr 2007 16:48:00 GMT
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.
Fri, 06 Apr 2007 04:15:24 GMT
It's been a good week for new (to me) Firefox extensions.
Any serious Firefox user will tell you that it's all about the extensions. Unfortunately, if you install enough extensions, you'll eventually encounter a conflict between the hotkeys registered by different extensions. A few extensions are nice enough to allow you to redefine the hotkeys. Most do not. I've been struggling with this lately - the Focus Last Selected Tab and Image Zoom extensions register conflicting hotkeys - I've been wanting to use the FLST version, but Image Zoom was taking priority.
I just ran across the keyconfig extension, which solved my problem handily. It allowed me to suppress the Image Zoom hotkey (it can also reassign operations to a different hotkey). Problem solved.
Fri, 06 Apr 2007 03:48:55 GMT
Generally, I find that the font sizes used on many, if not most, web sites, are too damn small - especially on a 15" UXGA laptop screen. To avoid having to hit Ctrl-+ (text zoom) on every page I visited, I've been increasing the the minimum font size in the Firefox Options dialog. But this isn't an ideal solution - it screws up the layout of a lot of web sites. And minimum means minimum - you can't use Ctrl- - to zoom out and shrink the text size.
This week I ran across the NoSquint Firefox extension, which offers a much better solution. It allows you to specify a default zoom level used when pages load. Moreover, it can remember zoom levels per-site, so that sites with particularly sadistic designers can be set to zoom in more by default. It ROCKS!
Wed, 28 Mar 2007 04:50:00 GMT
I've got a brand-spanking new, clean install of Vista on my laptop, and I'm trying to install Visual Studio 2005 on it. Unfortunately, I'm not getting very far. The installer always displays the following dialog, complaining that I don't have XP SP 2 installed:
The only related info I've found from Microsoft is on the VS2005 on Vista issue list, which states that "Visual Studio products fail to install in XP compatibility mode". However, I'm not selecting any compatibility mode when running the install. I've run the install as administrator, but no difference. I've tried disabling UAC, but no difference. Does anyone know how to get around this problem?
UPDATE - Although Scott Guthrie and crew graciously offered to help track down the problem, I haven't heard back from them after our initial exchange. However, based on other recommendations that I found online, I copied the DVD contents to my hard drive and successfully ran the install from there. My guess is that when the installer is run from the DVD it ends up running in XP compatibility mode - but I have no idea why.
Wed, 21 Mar 2007 22:53:00 GMT
I've been meaning to rename this blog for ages. The whole PuppiesAndIceCream thing was originally just a dumb joke from when I renamed the blog the first time, and I never meant for it to stick. But being the unimaginative person that I am, I never came up with another name, and so it has stayed.
Then I today I read Clemens post about Blogger Types, and his description of "The Blip In The Noise" so precisely matched this blog that I simply had to
steal adopt it. Hope you don't mind, Clemens - let me know if you do.
So, the puppies are gone and the ice cream is all eaten. We now return you to your regularly scheduled program.
Tue, 20 Mar 2007 04:34:00 GMT
For details and the download link, go here.
Thu, 15 Mar 2007 05:21:08 GMT
Am I the only one majorly annoyed by VMWare's support policy (or lack there-of) for VMWare on a Vista host? Apparently EMC's stance is that in order to run VMWare on a Vista host, we need to wait for VMWare 6.0. This presents several problems:
I've been a big fan of VMWare for a long time. It's a much more capable virtualization product than Virtual PC. I'd much rather use VMWare, even if it costs money and VPC is free. But they're not giving me a lot of outs here.
What's frustrating about the situation is that VMWare 5.5.3 almost works on a Vista host. The first time I start a VM after booting the host, my machine essentially locks up for 3-5 minutes while VMWare sucks up every resource the system has. But eventually it comes back to life and the VM works fine. And any VMs started after that work fine too - until I reboot my machine. Weird...but it seems like a problem that should be addressable in a 5.5.4 release (not that I know diddly about writing a virtualization product ;). I'm not asking for Vista guests, glass in a VM, or even UAC compatibility. Just the basics - don't lock up my machine when I run a VM.
I look forward to the super-cool features of VMWare 6.0 - I just can't be without a reliable virtualization product until then.
Thu, 15 Mar 2007 04:12:58 GMT
Ever since upgrading to Vista and Office 2007, I've had a really annoying problem with Outlook 2007. After running for a couple days, the UI would lose the ability to repaint itself correctly. It would glitch out and start drawing large blank regions or garbage. It smacked of a resource leak, but caused by what? I tried everything I could think of - upgrading the video drivers, disabling add-ins...nothing fixed the problem.
Finally one day I clued into something - I've been running the Outlook Appointments Sidebar Gadget for almost as long as I've been running Outlook 2007, but hadn't thought to try disabling it. Once I did, bingo, no more problems. My sources at Microsoft (actually, my sources sources) confirmed that this is actually a bug in Vista that's being triggered by the gadget. Apparently the gadget's author is working to mitigate the problem.
BTW, while trying to track down the problem I was monitoring Outlook's handle usage. Am I the only one who thinks Outlook using 2600 handles at startup (and >3200 after running for a while) seems a little excessive?
Thu, 08 Mar 2007 03:38:00 GMT
One of my co-workers was struggling with a strange problem recently - he installed SQL Server 2005 (with Analysis Services 2005), but the Business Intelligence Studio application didn't install. If you haven't seen it, BI Studio is really just a special version of the Visual Studio 2005 IDE, with Analysis Services-specific projects and editors. What he saw was that even though the SQL Server installer claimed to have installed it, and even created a shortcut for it, the actual devenv.exe executable wasn't installed (the shortcut pointed to an invalid path). I'd installed SQL Server many a time, and never seen this problem. A search of the MSDN forums turned up this helpful topic, with the following advice from 'softie Dan Jones:
go to the location for SQL Server setup and run .\Tools\Setup\vs_setup.exe. This will install the VS Shell. After this is installed repair the BI Studio installation by running the following from the command line from the .\Tools directory: start /wait setup.exe /qb REINSTALL=SQL_WarehouseDevWorkbench REINSTALLMODE=OMUS
My co-worker tried it, and bingo, problem solved. I've still seen no satisfactory explanation for what causes the problem in the first place. We had no other versions of Visual Studio installed, which some other people have claimed triggered the problem. Very curious.
Wed, 14 Feb 2007 06:08:01 GMT
I've been working a bit with the ASP.NET AJAX Control Toolkit (bit of a mouthful, isn't it?) recently. The toolkit consists mostly of a set of extender controls. In ASP.NET AJAX lingo, an extender is a control that attaches AJAX-y functionality to an existing ASP.NET server control. Each instance of an ASP.NET AJAX extender control is associated with a single instance of an ASP.NET server control through its TargetControlID property.
The .NET framework supports a similarly named but orthogonal concept, the Extender Provider. An extender provider is a component that provides properties to other components. At design-time, the IDE shows those properties as belonging to the extended control rather than the extender control. The prototypical example is the Windows Forms ToolTip component, which adds a ToolTip property to each control on a form.
Even though they both have the word "extender" in them, AJAX extender controls and extender provider controls are really totally different things. The extender control base class that the ASP.NET AJAX framework provides does not identify itself as an extender provider. The sole extender control provided by the core ASP.NET AJAX team, the DragOverlayExtender (part of the futures package - the core framework provides no extender controls out of the box) is not an extender provider.
The extender controls in the ASP.NET AJAX Control Toolkit, on the other hand, are almost all extender providers. They do this by way of the ExtenderControlBaseDesigner class, which is the base class for the control designers of most of the controls in the toolkit. This means that, for example, the auto-complete properties for the AutoComplete extender show up on the extended TextBox control, not the extender control itself.
So what's the point? The point is that the developer experience working with these controls is, in my estimation, kinda sucky. Why? Because you always have to set properties on both controls to do anything useful. The process of configuring a toolkit extender control requires picking the extender control in the designer, setting the TargetControlID property, then picking the extended control in the designer and set the extended properties there. What value is there in going to two different places? It's just a hassle for the developer, as far as I can see. Why not just put all of the properties on the extender itself?
In contrast, let's look at the other extender provider controls in the framework. ToolTip, HelpProvider, ErrorProvider, they all have something in common - they add properties to ALL controls on a form. The FlowLayoutPanel and TableLayoutPanel add properties to all controls contained within themselves. You don't pick a control to extend, so you don't have this two-step configuration process (ToolTip does let you set global settings on the component itself, but it's not a required first step, and those settings affect all controls).
The current design may be a holdover from previous CTPs of the AJAX toolkit, where a single extender control could extend multiple instances of a server control. In that case, it may have made more sense to have the per-control settings configured via properties that show up on the extended control itself. But in the RTM AJAX world, it's just a hassle.
Interestingly, one of the newest controls in the Toolkit, the Calendar control, doesn't expose itself as an extender provider. Is this an indication that the toolkit authors are moving away from that model? I hope so.
Fri, 12 Jan 2007 18:58:00 GMT
In a comment on my post about problems running Cropper on Vista, Chris Hammond pointed out the Snipping Tool that's built into Vista (Programs, Accessories. I wasn't aware of this tool - it's really quite cool! It allows you to draw a rectangle or free form shape on the screen, and captures whatever is displayed on the screen in that region (it also supports the standard window and fullscreen snapshot). Thanks for the pointer, Chris!
I have a feeling Vista is full of little stuff like this that I'll be discovering in the common months (if not years). Hell, there's still little things I'm discovering in XP! Is there some catalog of new little tasties like this described some where? The "What's New" documentation never seems to cover small stuff like this.