Mark Jackson, my co-founder at Cucku, is blogging re-mastered debugging tips from StackHash at infopurge.tumblr.com. StackHash is now an open source project on CodePlex and all of the great content from the original site has been taken offline. This new project is a great resource for debugging on the Windows platform, especially post-mortem crash dump analysis. If that’s your thing do yourself a favor and subscribe to Mark’s blog.
This has bitten me a few times. If you use Process.Start("url") it will work some of the time but you'll see a "The system cannot find the file specified" Win32Exception on some systems. Bummer.
Lots of people suggest looking up the HTTP handler in HKEY_CLASSES_ROOT but this is flawed as well - on my system for instance HTTP is registered to Firefox even though I'm actually using Chrome and I'd be unhappy waiting half an hour for Firefox to wake up and show the requested web page.
From XP there are a couple of registry settings tied to the current user's preferred browser.
First check HKEY_CURRENT_USER\Software\Clients\StartMenuInternet. This key will only exist if the user has overridden the system default browser - the default value is used to access the details (for me, it's chrome.exe).
If the user hasn't set a default then check HKEY_LOCAL_MACHINE\Software\Clients\StartMenuInternet. The default value here is the system default browser (on my system it's FIREFOX.EXE).
There is a set of subkeys under HKEY_LOCAL_MACHINE\Software\Clients\StartMenuInternet that contain details about each registered browser. The default value from StartMenuInternet (either HKCU or HKLM) is the subkey to look for. The path to my default browser is in this key:
Now I can Process.Start(path, url) to safely launch the default browser. You can fall back to Process.Start(url) if registry access fails for some reason, but be prepared for that Win32 exception.
I'm updating a screensaver so that it stops work once the monitor switches off. This seemed like a really simple requirement but it took some time to find an API that works on both XP and Vista.
My first attempt was ReadPwrScheme(). The documentation suggests using a different method on Vista - it should say so more strongly because on Vista you get back some default information that bears no relationship to reality.
Next I tried CallNtPowerInformation(). This doesn't mention any alternatives but also doesn't work on Vista. I've added comments on both MSDN pages pointing to the answer.
GetCurrentPowerPolicies() is just the ticket - it returns a wealth of information including the video timeout on AC and battery power and works on both XP and Vista.
Pinvoke.net has all the structures required but not the actual function. I've just added the C# interop signature for GetCurrentPowerPolicies().
I can't believe how frustrating finding this information has been. If you've found this post I hope it saves you a couple of hours :).