Use GIT, it’s very pratical to go back if something went wrong
I have a free account on BitBucket. Having version control, even for just me, has saved my rear end on many occasions. In my cases not from crashes, but from my stupidity/tweaking/not sure what I was doing 
basically this is exactly what the VCS file format is…
- The binary format is near impossible to parse with external tools (note I said “near”)
- The XML format is “difficult” {they do some strange things in there)
- The VCS format is easy-peasy
But VCS doesn’t support linking external files, making reuse among multiple projects much less natural and much more difficult.
And XML is XML, it’s legal XML and you don’t have to know the meanings of the data to repair files (which was the intent of my post). You just have to repair it so it’s legal XML. “Strange things”? Maybe strange data, but we don’t care about the data if we are repairing. We just want to get as much back as possible. It’s legal XML, that’s all that matters.
I’ve had issues like this before, one as recent as a week ago. Because the project file (in my case XML) was corrupted, REAL/Xojo choose to ignore the data it can’t read and usually comes up with an empty project. But by mere opening the XML in Firefox (it parses XML) you can see the parsing issues and repair it, saving your project. You might lose a thing or two, but you’ll save your project.
[quote=266073:@Michel Bujardet]Elders used to say their prayers at the end of a hard day’s work. Computer users should backup their data when the sun sets.
[/quote]
Or use something like Crashplan - it’s saved me a few times now.
Go preferences and set your default project format to Text.
Regardless, sharing external items can be dangerous anyway because Xojo doesn’t reload components on-the-fly if something changes. It would be much safer to use SVN Externals or the Git equivalent so you can lock your working copy to a particular revision of an external until you are ready to update it. I agree that it can be tricky to set up, but it does work.
The biggest challenge is that as we’ve improved the text format over the years and bugs have been fixed, the newer IDEs try to correct things as components are touched. If you work in an environment with multiple versions of Xojo (as many of you do) there will be constant changes to the non-code sections of the files as they fight over “what’s right”. This isn’t just vcp, but it’s most evident there.
VCS knows nothing about how the files under it’s control are used, so it neither supports nor prevents you from using external items. As far as it is concerned they are just a bunch of files, like any other bunch of files it has under it’s control. Where is your difficulty?
That was exactly my first thought… “external” files would just be part of the VCS repository for any/all projects the file was included in.
If you are using a Mac, a very handy app is called Foreversave. You can set it not only to keep a certain number of previous versions (or up to a certain size) of your documents, but you can set it to automatically save your files for applications that don’t already do so.
I too have experienced Xojo crashes on my Macbook Pro that have corrupted my files. One tip that works for me is that I save ALL my projects in Dropbox. That way if there’s a problem, you can log into the Dropbox site and restore an older version of your files.
15+ years using Xojo
8 as a Xojo employee and never seen Xojo just corrupt project
Wish I had because maybe we could diagnose & fix it
But I’m sure that reproducing it would be nearly impossible
IIRC, it happened to me when I was using Active-X controls (BootCamp). It was quite some time ago.
Im sure I have heard of many problems if you SAVE to a dropbox area.
COPY after saving locally would be be safer?
[quote=266580:@Jeff Tullin]Im sure I have heard of many problems if you SAVE to a dropbox area.
COPY after saving locally would be be safer?[/quote]
I’ve been saving all my source to Dropbox directly for about two years now (in multiple languages) and have never had a problem. I suppose there could be issues with database locking, etc. But I rarely work with db’s.
You are walking on the edge. As default, Xojo will generate executables for runs on the same disk as where the source was saved. This invites all sorts of potential problems, ranging from built not deleted between runs, to not updated, or even save not honored immediately, so your latest changes are lost.
The forum is full of such horror stories.
Cloud drives are great, but Jeff is right : work local, save local, and then copy to the cloud. In the process, you create two copies, which may become handy as well.
I found that working with Onedrive results in very slow compiles, Xojo not responding, saving problems etc. I use a Synology NAS as backup. I work local, as Michel advices, but when finished I run a XCOPY batchfile that copies all work to a \DEV share on the Synology. The contents of really important Synology folders (like \DEV) are automatically copied to the Onedrive cloud and to 2 separate connected low budget portable harddrives every night.
I was plagued by simultaneous crashing harddisks too often.
About cloud drives, I am not perfect. A while ago I tried placing my sources in the Google drive folder. On the surface it was OK, since that folder is local.
But the Google drive software locks files until they are synchronized. As a result, Xojo could not delete the temporary run build after it had quit, so when I tried to run again, I was told I could not. The same happened when I tried to build too early after a previous build.
That was not as bad as losing changes, but that is an example of what can happen when one works on a cloud drive.