There is nothing worse than having some notes in TextPad, to get pulled away from your computer, getting sidetracked, forgetting to come back, only for your machine to have decided to reboot, wiping out everything you've typed!
Please implement an auto recovery method so that unsaved documents (both never saved, as well as existing documents that just didn't get re-saved once the changes had been made) get backed up and are reopened (preferably with an indicator that they are "auto-recovered" documents so that I know which files are which) automatically the next time that TextPad opens. This recommendation follows Microsoft's autorecovery methods relatively closely to how it appears to the user.
My high level recommendation for implementation would be as follows:
new (unsaved) document is created, a temporary file (such as "DocumentX autorecovery 'timedate stamp'.txt") is created in %appdata%/TextPad/autorecovery for this unsaved/unnamed file. Every x minutes, the changes are pushed to the temporary file, and the filename timedate stamp is updated. Once the file is properly saved (without being autorecovered), the app then changes the DocumentX part of the file name to the saved filename. Upon successful closure of the document, the temporary file can be deleted as part of the closure process.
If TextPad either crashes or is closed unceremoniously (such as by a damned Windows Update reboot), when TextPad reopens, it scans the autorecovery folder for any files, and if there are any, opens them up for the user to recover. If the user does not specifically save them, then I would recommend the app ask the user specifically if they are done with the file Y/N, and if no, leave the file in the autorecovery folder to be opened next time until the user either saves the file correctly, or acknowledges that they are done with it.
Automatically save for recovery purposes unsaved documents
Moderators: AmigoJack, helios, bbadmin, Bob Hansen, MudGuard
Re: Automatically save for recovery purposes unsaved docs
What you want is fixing symptoms, not the culprit: why should every program on its own work out a recovery method when the operating system should be brought under control (instead of having its own mind)? Why do you consider TextPad the problem when Windows seems to be it? How do other applications deal with your "I leave unsaved content alone while automatic updates are active" approach?a damned Windows Update reboot
TextPad cannot reliably look into your mind if that one document which already exists but still has unsaved changes SHOULD be saved if the Windows session is about to end, nor is it suitable to backup a 300 MiB text file every x minutes just because the user decided right away all the content is not that much important to at least save it once.
TextPad could notice an ending Windows session (WM_QUERYENDSESSION and WM_ENDSESSION) and provide settings on how to deal with everything upon that - that would be an improvement. However, even this does not fully guarantee enough time to react (but should under normal conditions).
Re: Automatically save for recovery purposes unsaved docs
While I completely understand your point, reality is otherwise. Microsoft isn't going to change the way they handle updates, because they want to force the updates as quickly as possible to limit exposure time of buggy software. In fact, over the years, it has gone more and more the direction of fully automating the update process, and taking more and more control away from the user.What you want is fixing symptoms, not the culprit: why should every program on its own work out a recovery method when the operating system should be brought under control (instead of having its own mind)? Why do you consider TextPad the problem when Windows seems to be it? How do other applications deal with your "I leave unsaved content alone while automatic updates are active" approach?a damned Windows Update reboot
To your question about why I consider TextPad the problem, and how other applications deal with it, I don't consider TextPad the problem, I fully realize that it is a MS issue, but since as stated before, we know that MS isn't going to fix it the way we want them to, we are forced to look to the application developers to fix it in their software. And as stated in my original post, MS Office handles this reasonably gracefully by doing what I asked for, creating temporary backups of unsaved work in the user tempfile space, and recovering them back into the Office program the next time it is opened, to allow the user to decide what to do then (also, while I get what your saying about the user not saving the work, sometimes it just doesn't happen, whether because the user gets pulled away from their computer for what they think will be a few minutes, which turns into the rest of their workday so they just never make it back to their computer that day to save it, or just momentary forgetfulness, or god forbid, TextPad or the computer crashes before the user saved it).
Not expecting it to look into my mind, but (IMHO) I would reasonably expect the program to protect user documents in progress.TextPad cannot reliably look into your mind if that one document which already exists but still has unsaved changes SHOULD be saved if the Windows session is about to end, nor is it suitable to backup a 300 MiB text file every x minutes just because the user decided right away all the content is not that much important to at least save it once.
I would think doing that would also work, say for the unsaved documents, just name them something like "recovered-<<date×tamp>>-document#.txt", I was just thinking something more "elegant" that handles the recovery and removal upon user interaction automatically, vs just duming the documents into a directory.TextPad could notice an ending Windows session (WM_QUERYENDSESSION and WM_ENDSESSION) and provide settings on how to deal with everything upon that - that would be an improvement. However, even this does not fully guarantee enough time to react (but should under normal conditions).