This.
Damn, that’s nice.
Man, its dusty in here.
Anyhow, I’m always encountering this every once in a year, and it takes awhile to rediscover the solution, etc etc, so here it is.
(sorry, can’t look for a decent prettify WP addin right now)
<Border>
<Border.ToolTip>
<ToolTip
DataContext="{Binding Path=PlacementTarget.DataContext, RelativeSource={RelativeSource Self}}">
<TextBlock Text="{Binding}"/>
</ToolTip>
</Border.ToolTip>
</Border>I’m still not sure why the hell this isn’t the friggen status quo. Sup with that? Sup?
If I get unlazy I’ll extend the ToolTip class to set that binding automatically from within code.
On vacation, so I have a few seconds to post!
WARNING: Dirty hack ahead.
Here’s a little annoyance that’s been biting at my heels the past few days—how to connect to Team Foundation Server 2010 Source Control over a virtual private network (VPN).
I think it might be a common enough occurrence; people leave the office domain and still need to connect to source control. So they fire up a VPN connection and try to access the server.
In my case, I would experience timeouts. Whether I tried to connect through Visual Studio, or to the “server/tfs/web” website, whatever I tried would simply hang until the operation times out. I wasn’t able to locate any errors in the event log, in the firewall dropped packet log, or in IIS.
While attempting various solutions, I stumbled upon a dirty hack which can help you if you’re suffering the same issue.
What I did was I added a new binding to the Team Foundation Server for port 80. I had to delete the default website in IIS first, since it was already bound to port 80; I could have changed its binding to something other than 80 or specified a domain, but its useless and so into the recycle bin it went. I also didn’t change the default binding for TFS (port 8080) so I didn’t have to tell anybody to update their settings.
So, why did this work?
I. Don’t. Know.
That’s why (at this point) it’s a dirty hack. I guess I could spend an hour or so tracing through the settings within the firewall and IIS to find exactly what is different between a website bound to port 80 and the rules set up for TFS, but I decided to post the hack up instead.
Hope this helped!
This has happened to me twice on my current project; the last time it was passed from me to two other people in the team like the common cold.
Although I’m hoping to steer this blog from a “To do X perform these steps” snoozefest into a more meta-ish discussion of software development, I record the solution here for the benefit of super annoyed developers everywhere.
Problem: Automatic checkout on edit in Visual Studio has stopped working.
Possible causes: Visual Studio crashes; project files are corrupted in source control by these crashes.
Always check first: Tools -> Options -> Source Control -> Environment -> Editing: -> Check out automatically
Ready? Put on your grass skirt, grab your totem, snort some yopo and do the following:
Some of these steps may be cargo-cultish, but the problem is so nebulous its not for us to fully understand the meaning, but to mindlessly repeat the rituals so the source control gods will once again be in their good graces. Step 4 is definitely required; the others may be unnecessary. I’d test it but I hate when this bug happens; its like a paper cut in between your fingers. Not anything to stop you from functioning, but damnably annoying.

… And what to do about it.
I'm giving a presentation today to graduate and other students at USC about software development. I wrote a slideshow about it. Like to see it? Here it goes.
Taking a momentary break from an internal beta…
Does this compile?
var foo = newFooType()
{
AnInt = 1,
AnotherInt = 1,
MyBar = bar,
};
If you’re wondering what’s strange here, its the pointless last comma in the type initializer.
Apparently, the compiler doesn’t care. Which is a good thing, if you’re lazy. However, it could be an indication that you’ve forgotten something.
I’m voting its a bug in the compiler.
(Long after the fact update: Its not a bug. Its a common practice to allow the last comma in situations like this (delimited lists). This has been done for a long time in order to make it easier for automated code generators.)
I have to relearn this every time I want to do it, so I record it here for my benefit. You can stop reading now (unless you’re trying to do this yourself).
You’d think jQuery would have a nice little function/event you could hook into to handle this situation. Unfortunately, as far as I can see (and with 1.2.6), jQuery doesn’t provide an obvious way to do this. So if you’re here wondering how to do this using jQuery itself, you can stop reading now.
Now that we’ve gotten rid of the people who don’t care, lets get this done.
With the following html page snippet:
<span class="kwrd"><</span><span class="html">div</span><span class="kwrd">></span> <span class="kwrd"><</span><span class="html">textarea</span> <span class="attr">cols</span><span class="kwrd">="120"</span> <span class="attr">id</span><span class="kwrd">="editor"</span> <span class="attr">name</span><span class="kwrd">="editor"</span> <span class="attr">rows</span><span class="kwrd">="10"</span><span class="kwrd">></</span><span class="html">textarea</span><span class="kwrd">></span> <span class="kwrd"></</span><span class="html">div</span><span class="kwrd">></span> <span class="kwrd"><</span><span class="html">button</span> <span class="attr">id</span><span class="kwrd">="subby"</span> <span class="attr">type</span><span class="kwrd">="submit"</span> <span class="attr">value</span><span class="kwrd">="Save"</span><span class="kwrd">></span>Save<span class="kwrd"></</span><span class="html">button</span><span class="kwrd">></span>
The following script will warn users before browsing away:
<script type=<span class="str">"text/javascript"</span>>
<span class="rem">// After our HTML has loaded...</span>
$(document).ready(function() {<span class="rem">// disable the submit button until we have something to submit</span>
$(<span class="str">"#subby"</span>).attr(<span class="str">"disabled"</span>, <span class="str">"disabled"</span>);
<span class="rem">// when the user types in the editor...</span>
$(<span class="str">"#editor"</span>).keydown(function() {<span class="rem">// enable the submit button</span>
$(<span class="str">"#subby"</span>).attr(<span class="str">"disabled"</span>, <span class="str">""</span>);
<span class="rem">// tell the browser to warn before navigating away</span>
window.onbeforeunload = function() { <span class="kwrd">return</span> <span class="str">"Don't do it."</span>; };});<span class="rem">// when the submit button is clicked, disable the warning</span>
$(<span class="str">"#subby"</span>).click(function() { window.onbeforeunload = <span class="kwrd">null</span>; });});
});
</script>
When the edit page loads, we don’t want the user to submit the exact same thing back to the server, so we disable the submit button. Also, if nothing’s happened, we don’t want to bug the user about navigating away, so we don’t immediately set that warning.
If the user types in the textarea, we use this indication as a cheap and quick way to indicate that Changes Have Been Made. Of course, they might be useless changes depending on the context; if you want to do some additional work to determine if a “real” change has been made, go for it. Also note, this happens every time a keydown event fires in the textarea. I’m not claiming its good javascript, I just claim it warns the user before losing changes.
So, when the textarea has changes, I enable the submit button (by removing its disabled attribute value), and set the window.onbeforeunload callback function.
Note, you can’t access this function via $(“window”), you have to access it directly. I can’t tell you what that says about browser support; I can tell you that it works in gte IE7 and Chrome. And that’s not bad.
This callback function must return a string. This string is displayed in a warning dialog shown to the user prior to the browser leaving this particular page.
Lastly, when the submit button is clicked, we want to disable this warning lest the user get bugged before we post back to the server. You can do this by setting the window.onbeforeunload callback function to null.
Again, the keydown function I add to the textarea fires every time a key is pressed when the textarea has focus. I’d fix that, but I’m struggling with posting this from my laptop. I trust you’ll fix this issue. Also, since you’re touching the window in javascript directly and not through the soothing jQuery API, you might have issues in some browsers. I can confirm, agian, that it works fine in IE7 and Chrome.
I present to you a first peek at… Calculator 2008!
(Yes, its a joke. Picture ganked from this great article about ribbon UI at MSDN)
As expected, Silverlight 2 is RTM and will be available on the 14th of October. Scott took the first few minutes bragging about Silverlight's recent accomplishments, such as all the records for streaming broken by the Olympics broadcast by NBC. He also spoke about all the major players that will be releasing Silverlight content with the release of 2.0. Examples include BlockBuster, who will be using Silverlight for movie reviews, and AOL, who will be releasing a browser-hosted e-mail application using the plugin.
Probably the biggest news is that Microsoft is going to partner with Soyatech to bring Silverlight development to Eclipse on Windows and, later, on other desktops.
Another interesting bit of news is the creation of the Silverlight Control Pack project on Codeplex. I don't see it yet, but supposedly it has 11 controls ready to go and they are looking to hit 50+ controls in the coming few years. This is good news for people developing Silverlight apps as the default controls are a bit lacking.