Auto re-launch a file after an unexpected quit ?

Hi,

some days ago, I power off my computing before I quit the applications and one of these (that I create using Xojo) had a file (content saved state is long forgotten).

On the next power on (on the next morning), all applications were rlaunched (with the previous open documents).

The question is:

What must I do to get my document to re-open ?

There are various methods which include keeping statuses on all operations done by your app. For example, when you open a file, you record the process, the file name and the status “open” (as text, integer, whatever yoiu prefer. I like integers). When you close the file, you either remove the “open” entry, or record a “processed” status of some kind. More sophisticated applications will keep a full record of many different statuses for given documents or processes. Upon launch, your application scans the statuses and brings you back to whatever process with whatever file the status log says you were working on when the app was killed.

For simple processes, this works well. It quickly becomes very difficult to do for more complex processes, even impossible in some cases (when for example, specific actions must be performed to reach a certain status.).

Hi Louis,

Thank you for your answser.

After reading it, I conclude that there is no OS stuff to follow (API or whatever to do the job).

What I have to do is to create a file (at FileOpen and friends) and put in it all needed information (depending on the process complexity I want). At document close, I delete that file. If the application shut down, my application have to do its job (this job) and save the last piece of information that will be needed to re-open that file at next application time.

Is this correct ?

[quote=189165:@Louis Desjardins]There are various methods which include keeping statuses on all operations done by your app. For example, when you open a file, you record the process, the file name and the status “open” (as text, integer, whatever yoiu prefer. I like integers). When you close the file, you either remove the “open” entry, or record a “processed” status of some kind. More sophisticated applications will keep a full record of many different statuses for given documents or processes. Upon launch, your application scans the statuses and brings you back to whatever process with whatever file the status log says you were working on when the app was killed.

For simple processes, this works well. It quickly becomes very difficult to do for more complex processes, even impossible in some cases (when for example, specific actions must be performed to reach a certain status.).[/quote]

What you describe is what I call the ‘pianola’ method (piano mécanique). The player piano method consist into storing all actions into a file (keyboard, menus, and so on). Upon unexpected quit, when restart, the program reloads the current file and executes the whole session up to the quit. If I remember right, the Sprint word processor from Borland did that. It does require a high level of automation.

The much simpler way which is used by many applications including Xojo, is to regularly save a copy of the current document through a timer or current events like keyboard and menus. Additionally, the same file can contain caret position and scroll position for a word processor, for instance. If the program is quit the proper way, that file is simply discarded. If the program crashes, when it restarts, it finds that work copy and is able to start where it stopped. Some apps automatically load it, some others like Xojo ask if you want to go back where you were at crash time.

In the old times, Microsoft Word default save operation was to append every change. An option was available to save the whole document as it is in the document (better for rescue operations).

Still in Word and old times, Microsoft Word stored information (and its licnese #) in the file first 512 bytes, then the document storage started.

A decade (or two) ellapsed since the last time I used Microsoft Word, so…

[quote=189381:@Michel Bujardet]
The much simpler way which is used by many applications including Xojo, is to regularly save a copy of the current document through a timer or current events like keyboard and menus. [/quote]
I need to correct you here
Xojo does not “auto save” as you work
The only time it auto saves a copy is when you RUN
And of course when you explicitly Save your project

The upshot is if you work for several hours, do not run, then Xojo crashes you can lose all that work.
I think there is a feature request for a periodic save but I dont know the # off the top of my head

Eww… Please just leave it as is. Save when you want, leave the programmer in charge. Cmd/Ctrl-S should be in your work flow, when you complete a unit of work you do not wish to loose, save. That should be standard workflow in most programs you work in.

Never said we were implementing it :slight_smile:
Just that I think there was a request for such a thing.

[quote=189594:@Norman Palardy]The upshot is if you work for several hours, do not run, then Xojo crashes you can lose all that work.
I think there is a feature request for a periodic save but I dont know the # off the top of my head[/quote]

I stand corrected. Actually, it works fairly well already.

In an ideal world, that goes without saying. But sometimes, the IDE crashes altogether, not necessarily during a run, and all is lost. Most conspicuously, I have seen it happen time and again upon loading a project. For whatever reason, the IDE would quit silently, or get in the beach ball mode and never exit but for a force quit.

Adding periodical save of the ghost already existing on top of every run would add an extra layer of safety net, without changing a thing about what should indeed be a normal workflow. Should I add after a save, a copy should be put away in case anything happened to the work machine. A PC hard drive died on me not long ago, that was not pretty.