I’m looking for why Xojo is saving source files with true or “true”, or adding a property like TabStop, or adding “Enabled = True” to a socket, or adding “Index = -2147483648” to a control…
We developers of the same project have all the same version of Xojo, and all on Mac.
This displays differences in GIT, which in fact are not …
and 58970 and 63139 
Apparently xojo is made in xojo but they don’t have this annoyance made a priority #1. This is a huge time thief for any text project managed in git/svn.
5 Likes
We never said that we don’t have this problem. It just hasn’t been easy to track down. Everyone who has worked on the IDE over the last decade has tried to fix this and we have made some progress, but there are still a few particular properties that are eluding us.
Don’t use them then. I use Cornerstone 2.7 which uses subversion internally. It can present two versions of some file as jointly-scrolling panes in a window. It is therefore very easy to not just compare before and after, but also skip past the sort of non-change this thread refers to.
Nor did the above. It’s just that this issue seems to be nowhere near a priority. But it keeps being the #1 time wasting feature. Even when some bug reports are “fixed & verified” they are actually not “fixing” the issue. Some even seem to make things worse.
This is nothing personal, it’s just a fact we have to face on each day and even each commit.
2 Likes
Been there done that. We used cornerstone, gitkraken, github desktop and some others. Just fix the issue at the source instead of having some other tool fix an issue. Having tools is great but explaining those tools to many is not.
1 Like
It’s very personal to me and the team. We have spent a lot of time fixing issues that cause this behavior. Yes, there are still properties behaving badly, but it’s also happening for far fewer properties than it had before. This is unfortunately one of those bugs that is so time consuming that you literally have to put aside for a while to keep yourself sane. As I’ve said before, it’s not that we don’t want to fix it, we actually do. It’s just that it’s not as simple as just changing a single line of code… and if we get it wrong, VCP projects don’t save correctly and can’t be reopened. I think you’ll agree with me that a corrupt project could cost you a lot more time than the IDE flipping a control instance’s index on and off or flipping TabStop from True to “True” or vice versa.
2 Likes
It always seems to open no matter if it’s saved with “True”, “False”, True or False or “0”, 0 or -1055556 or “-1055556”
If only the saving would be consistent we wouldn’t have to review these annoying changes every time and it should not break things then.
You won’t hear anymore about this from me since you take it personal and i don’t like that.
Maybe a good idea would be to not write default properties (as they are default…)
What is the purpose to save ““Index = -2147483648” ?
TabStop=true ou “True” and “Index = -2147483648 is a real dayly nightmare for us.
One of the problem is caused by the fact that if you just open a “xojo_window” in the IDE without modifying anything, this window is marked as modified and will be saved…
It’s frequent that we need to open a “xojo_window” to see or copy some code without modifying it. Too late : it is marked to be saved with this #&&#&@ TabStop…
One of many things we’ve attempted I’m sorry to say. The problem with teaching the IDE to not write the default values is that then you can’t use those property names in your own projects without a lot of special case code on our part which makes it more complicated and error prone. It’s better to just get the IDE to do what it’s supposed to do and write the properties with the values it has.
Yup. Me too.
And the issue there is that the IDE as it stands today has no way to distinguish between a user initiated change or an internal change that was needed to simply display an item. We’ve got some ideas about solving that but they’re still in the design/experiment stage.
1 Like
PLEASE fix this.
This is a total mess.
Please fix this before anyone of you spends only one second on “New Desktop controls with API 2 events”.
5 Likes
I totally agree!
1 Like
You can’t imagine how many Git pushes we have in our Repo labeled as “Xojo Sh*t”. All those pushes contain only quirks like those mentioned in this Forum Thread.
1 Like
It’s a bit annoying but you can get used to it and manage what files you commit and push, it’s a little time wasting but I prefer that than getting my project corrupted.
If it was easy to fix, I tihnk it would be already fixed and a story of a past.
On the roadmap (I know it’s just indicative), there are some works planned on the IDE, maybe they will try to address it or to fix some properties.
Depends on how many projects you work on, how big those projects are and how often code changes. 
Those screenshots look fixed to me. They are removing the bad lines like AllowAutoDeactivate="True" and replacing them with the corrected versions such as AllowAutoDeactivate=True. At some point you will need to commit corrected versions. The issue is that they keep coming back. Certain properties, like TabStop, seem to like to switch back and forth so that True becomes "True" on one save, then "True" becomes True on the next.
So what happens if you commit that change. The next time you open the project and save again, does it put quotes around all those things again?