Here's a feature proposal that would give it the leg up over classic Notepad.
A feature similar to AutoRecovery in Office (although it doesn't need to be as sophisticated) to help users pick up their docs they may have lost unexpectedly, with a few caveats.
Rationale: Users will often keep Notepad open to use like a "sticky notes" app in that they write or paste things in it with as a temporary clipboard of sorts with no intention of ever saving it as a file. Notepad is primarily a file based app but we should support and keep in mind this use-case. Example scenario of losing unsaved data: You have something in Notepad, you minimize it, lock your computer and step away from it, Windows 10 decides to restart without warning, and bam your document is gone.
Solution: A simple, bare-bones caching system that allows users to recover files at startup.
Proposed implementation: On app startup, Notepad will asynchronously and lazily (i.e., once the app is fully loaded and a blank document is in view for the user to start typing) check if the cache file is present in the app directory (and is not empty) and make a copy of it to work with. If so, it gives users a non-intrusive option, perhaps at the bottom of the app window to restore it. If users have started typing already, they shouldn't lose their progress. We can discuss how it works.
We could have one cache file that stores unsaved changes (and is cleared out any time the Save command is used). One way is to use a timer. We could save the document every few seconds. We do not need to save every single character entered - that will just slow the app down. Users will be happy if they get 80 words out of 100 back.
This is what a workflow looks like:
Blank/opened document -> user starts typing -> this triggers the timer -> now there will be a delay (Thread.Sleep in a new thread perhaps) and contents will be written to cache AFTER 10 seconds or so -> timer will stop. Only if the user starts typing again, the timer will be triggered. This is important to make sure that we don't keep caching the same thing over and over even when the user isn't making any changes.
If there is an active timer already, no further timers will be triggered until this one finishes. That way, every keystroke doesn't start its own thread.
I don't know if this is feasible or even a good implementation. Let me know your thoughts and concerns + painfully obvious things I may have missed. I'll be happy to work on the code and see if it's working!
Here's a feature proposal that would give it the leg up over classic Notepad.
A feature similar to AutoRecovery in Office (although it doesn't need to be as sophisticated) to help users pick up their docs they may have lost unexpectedly, with a few caveats.
Rationale: Users will often keep Notepad open to use like a "sticky notes" app in that they write or paste things in it with as a temporary clipboard of sorts with no intention of ever saving it as a file. Notepad is primarily a file based app but we should support and keep in mind this use-case. Example scenario of losing unsaved data: You have something in Notepad, you minimize it, lock your computer and step away from it, Windows 10 decides to restart without warning, and bam your document is gone.
Solution: A simple, bare-bones caching system that allows users to recover files at startup.
Proposed implementation: On app startup, Notepad will asynchronously and lazily (i.e., once the app is fully loaded and a blank document is in view for the user to start typing) check if the cache file is present in the app directory (and is not empty) and make a copy of it to work with. If so, it gives users a non-intrusive option, perhaps at the bottom of the app window to restore it. If users have started typing already, they shouldn't lose their progress. We can discuss how it works. We could have one cache file that stores unsaved changes (and is cleared out any time the Save command is used). One way is to use a timer. We could save the document every few seconds. We do not need to save every single character entered - that will just slow the app down. Users will be happy if they get 80 words out of 100 back. This is what a workflow looks like: Blank/opened document -> user starts typing -> this triggers the timer -> now there will be a delay (
Thread.Sleepin a new thread perhaps) and contents will be written to cache AFTER 10 seconds or so -> timer will stop. Only if the user starts typing again, the timer will be triggered. This is important to make sure that we don't keep caching the same thing over and over even when the user isn't making any changes. If there is an active timer already, no further timers will be triggered until this one finishes. That way, every keystroke doesn't start its own thread.I don't know if this is feasible or even a good implementation. Let me know your thoughts and concerns + painfully obvious things I may have missed. I'll be happy to work on the code and see if it's working!