Slade's colleague had a hard time grasping why. It wasn't that he was slow, more that he just didn't care enough to think things through. In some lines of work that’s not too bad, but in software development, it can lead to “interesting” results. Case in point: a timeout dialog.

The task was to detect whether someone forgot to log-out of the application and, if so, log them out of the system. This was an important feature, as the application was responsible for divvying up time-sensitive data analysis work. The first attempt was pretty straight forward:

while(true)
{
    if (DateTime.Now > lastMouseActivity.AddMinutes(5))
    {
        doLogoff();
        showTimeout();
    }
    Thread.Sleep(100);
}

Of course, since a large portion of users' time was spent reading the screen, this code would simply log them off without warning. Slade explained to his colleague why this needed to be changed, and suggested confirming before logging off. This was the next attempt:

var logOutAfter = DateTime.Now.AddSeconds(30);

var dialogResult = MessageBox.Show(
    "Are you still there?\n\n"
    + "If not answered in 30 seconds, you will be logged off.",
    "Activity Check",
    MessageBoxButtons.YesNo);

if (DateTime.Now > logOutAfter || 
    dialogResult == DialogResult.No)
{
    doLogoff();
    showTimeout();
}

Naturally, this would produce a dialog box that looks something like this...

...and being that tbe program halts until either Yes or No is clicked, doLogoff() wouldn't execute until after the user indicated that he was not there or took too long to say that he was there. Slade was tempted to suggest that "Liar, Liar!" pop-up if the No button is ever clicked, but decided a better course of action was to try to explain why this code needed a little work and hope for the best.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!