I’m new in Xojo, I have latest Xojo 2019 2.1 on one Mac and when I pull my changes from Mac terminal via Git for example. Xojo IDE never gets updated. My Xojo project is a text based one.
So, Why Xojo does not get updates for .xojo_code files? Is there some tip to do it?
Particularly for me is very annoying to have to close the whole project every time that I want to pull changes from my Git repo.
have you tried with File -> Revert to Saved? i have never used it, so please do backup of your project before
But that’s how it works with Xojo IDE.
No you have not. Latest Xojo is 2019r3.
Hi @Jose Quintana
Xojo doesn’t includes a Git client in the IDE, so it is not aware about project file changes until you Close / Open again the project.
In this regard, 2019r3 appears to work the same as earlier versions.
I’ve been making more use of External Items in my projects. And although it is not documented as a feature, I find most times that if I collapse and expand again an External Item node in the Navigator, the Methods, Properties, etc. get refreshed. I’m just commenting here, not necessarily recommending it as a solution to your question.
I do however use “Revert to Saved” regularly, when I know the project file(s) have changed (like after pulling from GitHub) - but I always make sure my current local changes have been saved and committed beforehand. “Revert to Saved” closes and reloads the project in one step. Not an ideal solution, but I’m used to it now.
Nicols’ comment is the best solution and what I use many times a day to “undo” experiments in my code.
Here is my workflow: 1. Save project locally if it needs it. 2. Pull changes from remote source. 3. IDE will have revert to save grayed out so I change something minor. 4. Revert to Saved
I have been playing with external items and editing code in one ide, after saving it the changes in the code auto appear in the other ide.
Works very well actually.
Don’t think I did anything to tickle it.
I am sure that external items are checked for changes every time you select them.
Since Xojo is not a real-time collaboration IDE, why should internal elements be checked for changes? The IDE is already slow enough for some of us…
[quote=468651:@Graham Busch]Don’t think I did anything to tickle it.
The IDE is able to talk to itself, so no “tickling” needed :). What it doesn’t do is notice changes created by other tools such as manual edits in VSCode, GIT pulls, CVS checkouts, etc.
Usually I do
- save (unless this REALLY is an experiment I want to throw away then I will skip this)
- update from Git/SVN etc
- change something in the IDE
- revert to saved and reply yes really revert
Why don’t you file a Feedback Request to rename “Revert to saved” to “Reload Project” and have that available anytime (not just when the project is “dirty”, e.g. after a simple/silly change). It would save you two steps (1. having to make a change, 2. having to confirm to loose that change).
Have at it
I just dont care about that because its so trivial to do
I wiss the IDE worked more like BBEdit, which appears to check all files on disk for changes when the app is Activated, and any changed content is updated (optionally with a per-window dialog).
Might it be time to raise this Feedback Feature Request from the grave - feedback://showreport?report_id=19036?
If I have edits in some code in a running instance I sure dont want it to just load changes from GIT/SVN right over top of that
ANd that means now you’re going to have to shove a diff client of some kind into Xojo and … blech
I’m more interested in being able to check in, compare, view logs, and check out code rather than automatically noticing a change on disk. I’m with you in that I wouldn’t want my session to supersede my current edits because of a change made outside of the IDE.
Itsexactly why I do what I do and use SVN/Git and the tools they provde for managing this and then just have Xojo revert project which reloads it from disk when things are ready
I did submit a feature request to be able to right click on a single item and reload that one item from disk which would ease some of this
I’ve requested that feature about two years ago…: feedback://showreport?report_id=50426
With a .xojo_project, a possible workaround is:
- delete the project item
- drag-and-drop the project item again from disk into the navigator
It’s downside is that usually the project file gets modified because of that…