Since several months (years?) now, when Xojo crashes, the ability of Xojo to recover unsaved changes is broken (in my experience, it now never works). I’d not be surprised to see unreliable behavior on saving.
Except this isn’t about crashing and I worked along blissfully unaware for nearly three days without realizing and all of my work was saved.
It did it again! Updated to Big Sur 11.2.2 this morning and the project file went binary. Son of a biscuit!
1 Like
This is turning into a horror show. What I did was I saved as binary into another folder. Opened that and converted to project file. Copied just the .xojo_project file back into the Git managed folder. Now it’s back to showing the project file as a single file.
1 Like
The IDE allows you to save a xojo_binary_project into a file with the extention xojo_project which should ofcourse NEVER be possible, still it happens and xojo happily allows it…
That means there is no way .gitignore “*.xojo_binary_project” would help here. The only thing is to evaluate the contents always, but you loose all your edits ALWAYS when this happens.
1 Like
Many, including myself, would disagree that the software should overrule what I provided as the destination save name. Imagine your hammer telling you where you can put the nail you’re securing…
Wel i think at least the ide should ASK you to overwrite it since the contents of the file is completely different just writing the contents of a “xojo_binary_project” into a “xojo_project” isn’t going to be the action most of us want. Specifically when you do SAVE (e.g. IDE save as is), instead of “Save As” (e.g. i want the ide to save as i select).
→ And you can always change the extention name yourself as provided by the OS.
Yes, I agree the IDE should alert you “When you opened this it was source control friendly, but your license is gone so now we will save as binary.”
That should have nothing to do with the name of anything 
Not sure what you mean.
When i do save as. i mean if i type a filename and a extention it should just do that.
but when i do a plain save, nobody says the ide to save the binary content into a text project…?
I don’t know any tool that would do that by default.
Your initial suggestion was that if a user is saving as binary, the IDE should force an extension.
When you decide which stance you’d like to take, I’d be happy to revisit this discussion.
YES but ONLY when i do a “SAVE” CTRL+S/CMD+S (overwrite) and NOT when i do a “SAVE AS” .
That’s ridiculous when it could be implemented so that the IDE warns based on project type.
Again, I agree that if the IDE opens the project and wants to save it as a different type (due to license change) there should be a confirmation dialog.
This should have nothing to do with the name of the file the user chose.
so you didn’t read or didn’t follow?
“Save” is a different action than “Save As”?
When you open a project, the ide knows it’s a “text” project for example. So when i press “save” (CTRL+S or CMD+S) i must be able to expect it to save to the same format. But when the ide has no license it can’t save to text format. So one should be able to expect the ide to ASK then what to do, since it knew it was a text project.
I’ve never said this… i said to KEEP the extention and it’s content type as-is.
i said this:
The IDE allows you to save a xojo_binary_project into a file with the extention xojo_project which should ofcourse NEVER be possible, still it happens and xojo happily allows it…
By means of the content into another type.
This was not part of the discussion we were having at all. See your initial statement:
you interpret it diffrently that’s fine. The IDE has an issue here that causes pain again, that’s all folks.
I’m learning as I go and it was easier to recover this time. It’s the github management I don’t want to lose. I’m not going to lose my changes. I’m updating an older app for deprecated code rather than working on something for a few hours and saving. I started with about 2000 issues. I make very few updates and then I make a commit with a note about what I did. So I caught this right away. Here’s my steps. Maybe there’s a better way or maybe I’m heading toward more difficulty.
- Save as a binary project to a folder on the desktop.
- Open that binary project and make sure it has all the latest code.
- Save as a .xojo_project file into a new folder on the desktop.
- Copy all these files into the git managed repository file.
- Now you have a bunch of files to commit. Sort through them and do that.
The corrupt .xojo_project file size was about 8MB. The recovered .xojo_project file was about 6KB. When I say that I figured I had it right.
What is the case ID?
Thanks for asking. The case ID is 63788. Today it was reported as fixed and awaiting verification.
2 Likes
Great news, hopefully it makes it into the next release.
1 Like