State Street Gang
.NET, straight up

BRB

November 2, 2009 07:51 by Will

Been working hard on my IRL job, am about to go live with a point of sale system I wrote (with a little help from my friends) for a local bar, as well as a survey website I wrote and host for my best friend’s PhD dissertation. 

When I put it like that, it even seems to me like I haven’t been slacking.

I hope to dust this site off and put some good content up here in the new year.  Possibly move the blog to the cloud, which is starting to look more and more interesting lately…


Tags:
Categories:
Actions: E-mail | Permalink | Comments (0) | Comment RSSRSS comment feed

Has automatic checkout stopped working for you in Visual Studio?

March 24, 2009 14:15 by will

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:

  1. Check in everything
  2. Close visual studio
  3. Make sure every file is set to read only in the solution directory (set it on the root solution folder and configure it to propagate to children)
  4. Search for all files under the root projet directory *.user and *.vssscc and delete them (this might be overkill; one or the other may be the culprit but deleting both types won't hurt you)
  5. Open VS and load the solution
  6. Check everything back out and then check everything back in

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.


Tags:
Categories: Nuts
Actions: E-mail | Permalink | Comments (0) | Comment RSSRSS comment feed

What CS departments don't tell you...

March 20, 2009 12:43 by Will

... 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.


Does this compile?

February 17, 2009 09:34 by will

Taking a momentary break from an internal beta...

Does this compile?

var foo = new FooType()

    {

        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.

 


Tags:
Categories: C# | CLR
Actions: E-mail | Permalink | Comments (1) | Comment RSSRSS comment feed

Warn before navigating away using jQuery

January 17, 2009 16:15 by will

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.

The Code

With the following html page snippet:

<div>
    <textarea cols="120" id="editor" name="editor" rows="10"></textarea>
</div>
<button id="subby" type="submit" value="Save">Save</button> 

The following script will warn users before browsing away:

<script type="text/javascript">
    // After our HTML has loaded...
    $(document).ready(function() {
        // disable the submit button until we have something to submit
        $("#subby").attr("disabled", "disabled");
        // when the user types in the editor...
        $("#editor").keydown(function() {
            // enable the submit button
            $("#subby").attr("disabled", "");
            // tell the browser to warn before navigating away
            window.onbeforeunload = function() { return "Don't do it."; };});
        // when the submit button is clicked, disable the warning
        $("#subby").click(function() { window.onbeforeunload = null; });
        });
    });
</script>

What's going on here?

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.

Caveats

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. 


Tags:
Categories:
Actions: E-mail | Permalink | Comments (1) | Comment RSSRSS comment feed