Closed GoogleCodeExporter closed 8 years ago
EOF's current undo system probably makes this unnecessary. If the program
crashed, the last-modified .undo file could just be loaded. It's not
automatic, but making it automated would be a huge amount of work.
Original comment by raynebc
on 17 Oct 2011 at 11:50
Being able to have multiple EOFs running at once complicates this, although
doing so is probably not going to be the most common use. This could be
implemented as one or more files. If an eof.recover.on file does not exist in
EOF's program folder during launch, it will be assumed that no other EOF
process is performing this function and the file will be created and LEFT OPEN
to prevent a second instance from doing it. When an undo state is made, an
eof.recover file can be opened and the full file path to that undo state can be
written to file. During normal program exit, the eof.recover and
eof.recover.on files can be deleted.
During launch, if the eof.recover.on file is found, the EOF instance can test
to see if there was a crash condition by attempting to delete the file. If it
still exists after a deletion attempt, it's because another EOF instance is
running with that lock file still open. Otherwise it can be assumed that the
file remains due to a crash from a previous instance. If eof.recover exists
and contains a path to a file that exists, EOF can offer to reload that undo
state. If the user opts to do so, the undo state is loaded. After the auto
recovery prompt is answered, the recovery files can be deleted so that this EOF
instance.
Original comment by raynebc
on 18 May 2012 at 7:10
..can maintain the path to the last undo state.
Original comment by raynebc
on 18 May 2012 at 7:13
Original comment by raynebc
on 18 May 2012 at 11:35
Completed in r902.
Original comment by raynebc
on 22 May 2012 at 9:18
Original issue reported on code.google.com by
raynebc
on 25 Mar 2011 at 3:28