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.
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!
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.
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.
For details and the download link, go here.
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:
- VMWare 6.0 is only in it's first beta. VMWare major release cycles are not typically short. They're usually a least a couple betas and one or two release candidates. That means we'll be waiting a while.
- VMWare betas contain instrumentation that slow down their performance.
- New VMWare versions come with updated VMWare Tools that aren't generally backward compatible with older versions. That makes interoperability with users of pre-6.x versions problematic.
- Major VMWare upgrades usually cost.
- VMWare 6.0 beta is...well...beta.
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.
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?
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:
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.
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.
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.
More Posts « Previous page
- Next page »