I have moved my projects to use xojo_project fileformat and I’m now using Bitbucket and SourceTree client. Running on Windows 10 and Xojo 2016r4.1 I see in many cases that files that I have not edited actively are being changed.
The change is always adding or removing TabStop property from all the test labels. If the property is not there it is added and if it is there it is removed. I have several commits in Bitbucket because of this.
In the case you submitted the change is correct.
Older ID’s may have removed it and the IDE is trying to put the property back.
IF you revert this change then you’ll have to revert it every time as the IDE will continue to to put the property back on the item.
Some properties used to flip between using a quoted value and not - that had everything to do with using variants.
But in some older IDE’s labels didn’t save the tabstop property and some did so you might see that flip from being present to not being present with an older IDE.
I believe we have fixed this and labels should have a tabstop property - on OS X for when you turn on full keyboard access & on Windows & Linux all the time (and there are other controls where you might see the tabstop property get added)
What we have done internally is open the IDE project, analyzed the project, and then touched one file with a minor change like adding a space then removing it and then checked in all these changes in one fell swoop
And I’m no longer seeing these types of changes in the IDE sources
The long & short of this is “Its not a bug that the IDE is trying to fix the project but if you revert it then you will have to revert it forever”
Check the change in and it will stop trying to make that change.
HOW you do one or more is up to you.
So am I understanding correctly that Analyze Project will touch everything and make all the TabStop changes that will ever need to be made all at once?
Analyze or compile may touch way more than it should (at the moment) - not WILL
Analyze basically does a “debug run” and then doesn’t run the project
So only things that would compile for the current target will be analyzed (and possibly touched)
Code that would not be used for the current target won’t get examined
If its in #if Target that excludes that code from being compiled then you wont get notified of issues in that code
Compiling can have the same effect
The current incarnation of ANALYZE, COMPILE and DEBUG run can cause certain items to be marked as dirty
Thats a long standing bug as compiling or analyzing should not cause items to be marked dirty (see <https://xojo.com/issue/47248>)
The real takeaway here is “Dont revert those changes as you will have to revert them for ever if you do”
But some of us have… issues.
Is there a way to have everything touched at once so it can be one commit?
Is that something that would be worth a Feature Request or would it get ignored “Reviewed” for years?
Yes I know you do
But why would you persistently revert things the IDE tries to update ?
What I’m saying is “dont do that” - but if you like having to revert every change then go for it
There isn’t
You can file feature requests for anything you’d like
There really shouldn’t need to be a “touch every file” if the IDE only touches those you actually do any work on
[quote=320452:@Norman Palardy]You can file feature requests for anything you’d like
There really shouldn’t need to be a “touch every file” if the IDE only touches those you actually do any work on[/quote]
You know that’s not the answer I’m looking for
It would be nice to have a single commit where it’s just the things the IDE needed to update. Obsessive compulsive issues aside, if I’m looking for where something important might have changed I don’t want to sift through files that are only TabStop changes.
@Norman Palardy
OK - I have now ran Analyze Project, made a small code change and saved the project. 29 files were changed. I have now committed and pushed all these files. Should this be the end of this problem or will I see it happening again?
I only edit and open this project in 2016r4.1 and no-one else is working on the project.
As I said see previously
The current incarnation of ANALYZE, COMPILE and DEBUG run can cause certain items to be marked as dirty
Thats a long standing bug as compiling or analyzing should not cause items to be marked dirty (see (https://xojo.com/issue/47248)]Feedback Case #47248)
OK, I’m cool with that. I can agree that “analyze” shouldn’t change anything (unless I fix stuff). After being involved in a python project where indentation and whitespaces really matters I am sensitive to code changes…
Since you have the “Auto Increment Version” option I hope that builds with this on will still mark the project as dirty.
In changes I’m committing right now a TabStop on a label is disappearing (that wasn’t the change I made,) can’t wait to see it come back at some random point in the future… Is there a way we can help you debug this?
Sorry for resurrecting this old thread.
I have now noticed that when I run a IDE Script to build 64-bit Windows version, TabStop property is toggled in the entire project. I will try to isolate this further.
Tim, I’ve noticed a few times that when the “TabStops=True” appeared in my source control (literally dozens and dozens and dozens of instances just appear at once), if I reopened the project, made a Module the active the tab in the IDE and then did a Control-K (I’m mostly on Windows) then saved the project (making sure it was dirty before saving) the TabStop changes went away, all of them. I used to just revert the file when this happened, but this seems to correct it somehow and is better and I can continue on my way. I have no idea if it helps on the Mac.
Thanks for the follow up, Lee. Right, I was just pointing out that I used to initially try to clean them in version control. Then I just started reverting the file back in version control. Until I found out I could just open up a module and analyze and it would change them back. When I analyze it in the main window with all the controls that changed, it doesn’t seem to revert them back.
