
When I implemented Auto Save in our Notepad clone this past week, I noted that the new feature was “quick and dirty.” It was, perhaps, a bit too much of both: As a reader pointed out, the Save As dialog that will appear after 30 seconds could fire while the user was viewing the Message Box-based prompt asking you whether you wanted to disable the auto-save functionality, which could lead to some problems. I wrote a fix for that issue quickly; I actually changed the code in the original article that same day because I felt it was important to do so. But I also realized that it could happen whenever the application was displaying a dialog of any kind, including File Open, File Save, various message boxes, and more. So we will need to make a similar fix in each case.
And there are a lot of them.
My first thought was that whenever the application displays a dialog box, we would need to check whether Auto Save is enabled. If it is, we would then need to disable the interval timer that triggers an auto-save, and then we would likewise need to reenable the interval timer when the dialog box closes.
But that approach is kind of unsophisticated: The only time the interval timer really needs to be disabled is when the auto-save would display a Save As dialog. That is, if the current document is saved, then the auto-save can just happen in the background, and we don’t need to worry about disabling and then reenabling the interval timer.
So this should be an easy thing to fix. The problem is that we need to make sure we make it in every instance in which we display a dialog box of any kind. So instead of writing the same code in many event handlers, we’ll create two methods of our own and call them instead. The first will be called before a dialog box is displayed, and will look like so:
Private Sub CheckTimerInterval() If TextHasChanged = True And DocumentName = "" And AutoSaveToolStripMenuItem.Checked Then Timer1.Enabled = False End If End Sub
In English: If the text has changed, the document has not been saved, and Auto Save is enabled, then we will disable the timer.
The second method will be called after a dialog box is displayed. It makes the same checks and then disables the timer if required:
Private Sub ResetTimerInterval() If TextHasChanged = True And DocumentName = "" And AutoSaveToolStripMenuItem.Checked Then Timer1.Enabled = True End If End Sub
After creating those two new methods at the bottom of Form1.vb, we need to figure out where to call them. There are, unfortunately, multiple places we will need to do so.
The first is the FontToolStripMenuItem_Click event handler, which currently looks like so:

But it will look like this after we add our calls to CheckTimerInterval and ResetTimerInterval:

OK, so that’s not so terrible. But we need to make similar changes to the following event handers too:
Additionally, there are some other event handlers—like SaveToolStripMenuItem_Click, SaveFileDialog1_FileOk, and SearchWithBingToolStripMenuItem_Click—that display an error message in a Message Box if an exception occurs. I’m not going to bother adding any code to suppress a possible Save As dialog in those cases, but if you want to do so, I would just add the CheckTimerInterval() call before MessageBox.Show(ex.Message) and then add ResetTimerInterval() after it, in each case.
Finally, we need to make a change to the Form1_Closing event handler. This one is a little different because the application is closing and is performing some housekeeping tasks. So all we really need to do is just disable that timer. So just add this one line of code at the top, inside the event handler:
Timer1.Enabled = False
And … yeah. That is a lot of work to make sure Auto Save isn’t as buggy as it was originally.
And that raises a bigger issue related to the notion that code always gets bigger, buggier, and harder to read as it evolves: When I first started this project over two months ago, I wasn’t sure how much of Notepad I’d be able to duplicate, and I certainly wasn’t thinking about adding additional features on top of it. As a result, I didn’t really do what any real programmer should do, which is document—via comments in the code—everything. There is literally no comment-based documentation at all.
That’s on me, of course. But as the code has grown bigger and more unwieldy, it’s also gotten harder to understand, update, and fix. There are lots of things I’d now do differently, given what I’ve learned while writing this application. But it’s too late for that, unless I want to just restart it from scratch. Which I don’t.
Anyway. We’re not done fixing bugs yet: M. Lerch raised a few issues related to Auto Save that I’ll be looking at soon. And it wouldn’t surprise me to discover that the fixes we added today will cause some new issues. It never ends…
Also, just as a random aside, I see our app as a Windows 10 thing, but I finally tested NotepadWF in Windows 7 and it mostly looks pretty good. We don’t get the Aero Glass-style menu bar that the real Notepad has. And the checkboxes in the menus are just weird looking rectangles, probably related to high-DPI support (this is a non-high-DPI PC). But interesting, regardless.

With technology shaping our everyday lives, how could we not dig deeper?
Thurrott Premium delivers an honest and thorough perspective about the technologies we use and rely on everyday. Discover deeper content as a Premium member.