I have grown very tired of the Aero-style Alt-Tab behavior in Windows 7 (only took 4 weeks to get sick of it!), and I really wanted to revert back to the “classic Alt-Tab” behavior and make it my default. The former is easy. The latter requires a little regedit hack:

• Create a DWORD called “AltTabSettings” in \HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer
• Set its value to 1.
• Test Alt-Tab combination. The Windows XP-style AltTab behavior should have returned.

Thanks to a comment from “barbudo” on this page for the answer to this mildly-perplexing problem (scroll down to the comments).

Setup

1. I have my Visual Studio 2008 options set to reload the previously loaded solution on startup.
2. I use Subversion.
3. I use AnkhSVN as my SVN provider in Visual Studio 2008.

Problem
If I launched Visual Studio 2008 with a particular solution loaded when I last closed VS, I would receive a “Source control provider could not be found” error.

However… if I just launched it via double-clicking on the .SLN file in my file system, no error!!!

Weird.

OK – so I did a quick diff on a solution that I knew worked fine. Both had the expected source control provider information embedded:

SccProjectName = "Svn"
SccAuxPath = "Svn"
SccLocalPath = "Svn"
SccProvider = "SubversionScc"

However there was a difference.

The solution that did not generate the error message also contained the following block in the “Global” section:

GlobalSection(SubversionScc) = preSolution
    Svn-Managed = True
    Manager = AnkhSVN - Subversion Support for Visual Studio
EndGlobalSection

Which somehow got generated in one solution, but not the one causing problems. Once I copied the block from one solution to the other, the error message ceased to be shown on launch of VS2008.

var dsource = dashcode.getDataSource("list");
var name = dsource.selection().valueForKey("name");
document.location =
    ("http://www.google.com/search?client=googlet&q="
    + name);

But your first thought when looking at this may be (as was mine), “what if there are spaces or other characters in the “name” value that are not legal in an URL?

So then I set out to use one of the standard functions for escaping URIs: encodeURIComponent.

Unfortunately, when I entered the function I spelled it encodeUriComponent using camel case, which is what I thought was appropriate in this situation. Evidently not. I even was referencing good ol’ w3schools on the subject too.

But once again it kind of gets back to the whole “was it getElementByID or getElementById?” dilemma. And, unfortunately, unlike Visual Studio, there wasn’t IntelliSense in this case.

So then I set out looking to see why it was bombing, thinking that it was maybe a problem in Mobile Safari, like it didn’t support the function. I switched to escape and that worked just fine.

Then I looked more closely at the w3schools page and noticed the difference.

DUH.

Felt real stupid too.

But when using the function with the correct spelling/capitalization it worked just fine. Whew!!!

I guess I should have just copy-n-pasted.

;)

I tried using the log4net appenders ConsoleAppender and ColoredConsoleAppender, to no avail. Turns out there’s a different appender that works with the Output window, and it’s not ConsoleAppender.

The appender in question is TraceAppender!

So here’s a little snippet of XML from my web.config files that handles output to the Output window (basically the same markup as appears on the log4net examples page):

  </log4net>
    <appender name="TraceAppender" type="log4net.Appender.TraceAppender">
      <layout type="log4net.Layout.PatternLayout">
        <conversionPattern value="%d [%t] %-5p %c %m%n"/>
      </layout>
    </appender>

    <root>
      <level value="ALL"/>
      <appender-ref ref="TraceAppender"/>
    </root>
  </log4net>

To those familiar with the way the log4net section looks in your web.config this will make sense, but the key concept is that, per the log4net documentation, “Events are written using the System.Diagnostics.Trace.Write(string,string) method” — and it turns out that one of the listeners is the Output window!

A colleague of mine and I were very confused by all this (I’m glad I wansn’t alone in that feeling either!), but we were both very glad to figure this one out.

Thanks go to Google (of course), and this post on the SharpDevelop forums.

Every time I log into one of my online banking systems, I get a message like the following:

This is just intrusive and rude behavior (as Alan Cooper might say). First of all, the message first off tells me when the last unsuccessful attempt was made to access the account… HUH??? Then it tries to be helpful and tell me when the last successful attempt was made.

It just makes no sense at all to me why this message exists at all. Why would I ever care about these particular statistics, and even if I did care about them, is it really necessary to pop up a message box every time I log in???

I vote no.

Fine. If you want to have that information accessible, provide a log of all accesses tucked away in my account settings or somewhere I can get to if I think I have a security concern. Don’t show this message to me, please. What this message boils down to is a debug-ish message in the clothing of security (I could be wrong, but that’s what it smells like to me).

Interestingly, as a side note, I happen to know that this system is from a company that is now owned by Intuit (my former stomping ground), and in the two or more years since that acquisition, this message box has surprisingly still not disappeared.

Is it just me or is that a ludicrous choice? Why not a space (my preference – a la delicious) or a comma?

In addition, there is no example visible to show you what the legal delimiter is! You have to miraculously divine what it wants, or let it show you what it wants, as I chose to do.

To find out what the delimiter is, I had to do the following:

1. Open the “Select Tags…” dialog.
2. Select two (short) tags. (I notice lots of other folks thought that a space would be a logical delimiter too…!)
3. Close the dialog.
4. Oops. Closing the dialog didn’t populate the text box with my selections. Awesome.
5. Trying again… Open the “Select Tags…” dialog.
6. Select two (short) tags, this time at the end of the list where I notice OK and Cancel buttons (yes – you heard that right. The buttons are embedded in the list itself… and at the bottom of the list, no less! They’re not on the dialog “window.”)
7. Click OK.
8. Observe that text box has the new selections delimited by semicolons.

The auto-populating text box is another usability nightmare deserving of its own article, but I’ll let someone else write that one up. ;)