This is for example from a Windows machine (git) it changes files to this, this example is a xojo_window file:
TabStop = True
being added again (without the quotes around True). So there can be and IS a difference between the ide on macOS to macOS changes and Windows to MacOS.
Well it should be without the quotes in the long run. That’s what I’m getting at.
The major annoyance for me, it would alternate, with or without quotes, but not consistently.
This is probably the crux of the problem. If it were consistent, it would be easier to fix. Intermittent failures are the bane of any programmers existence.
I could not figure out how to outsmart it.
Edit-save, Edit-save, Edit-save. Hmmm no quotes and looks consistent… ‘commit’. Edit-save, Edit-save… oh joy! new quotes… Edit-save… Edit-save… ‘No quotes’. Back and forth ad nauseum.
Fortunately I don’t use git so I don’t know what a “push” is.
The thing I don’t understand about this hard to fix bug is while I know the goal is to find the, ahem, “true” culprit, or crux of the issue, why not in the meantime simply add a final pass filter in the text output stage to “solve” the issue. Yes it’s a band-aid, but the end result is the same – standardize these values!
…Or put into example code:
// FixMe: Temporary patch to filter out buggy quotes around values
// until we can find the true cause!
dim filterQuotes as Boolean
if codeLine.Instr(" TabStop = ") > 0 then filterQuotes = True
if codeLine.Instr(" TabIndex = ") > 0 then filterQuotes = True
if codeLine.Instr(" ..etc..
if filterQuotes then
codeLine = codeLine.ReplaceAll("""" , "") // Remove the quotes
EndIfDont workaround a bug you be able to fix yourself in your code!
Alright, I’m done trying to help. This will get fixed when it gets fixed.
Yes but its been an annoyance for over a decade. A temporary workaround is better than waiting even longer. If putting a filter stage right before outputting the files seems too cringe, then they could add a solution even closer to the source of problem.
For example, they have previously stated (I believe in one of the Feedback reports) the IDE is using Variants internally for holding property values, and thus somehow these value gets flipped back and forth from Boolean to String, or Integer to String, when serializing for text project files.
So they could add a patch to always render the Variant values as expected when they serialize things, like this hypothetical example:
dim codeLines() as string
For Each property as Pair in properties()
// properties() is a Pair of Variants to serialize
Dim propertyName as String = property.Left
Dim propertyValue as String = property.Right
// -- FIXME: Temporary patch to force proper format
Select Case propertyName
Case "TabStop"
propertyValue = str( property.Right.BooleanValue ) // Force Boolean
Case "TabIndex"
propertyValue = str( property.Right.IntegerValue ) // Force Integer
Case " ...etc... "
End
// -- FIXME: End of patch
codeLines.append " " + propertyName + " = " + propertyValue
Next
I wasn’t asking for help, and sorry if hit a nerve. I already have my own “Fix VCS Gremlins” IDE Script that touches every window in my projects to clear up the issues (which I’ve included in a couple Feedback posts over the years to help others.) I was simply curious if adding a temporary filter was considered in the meantime.
A total mess that is sold as a “pro” feature 
We hear this from Xojo, Inc. all too often about far too many things.
Antagonizing members of the Xojo team will do nothing to get this fixed sooner. They know it’s a problem, they’re working on it, and they said that they don’t need anymore reproduction information.
Helpful posts about mitigating the issue from here on, please.
Here’s my “Fix VCS Gremlins” IDE Script if anyone finds it useful (updated for 2020r1+ from the 2013 version I posted here: <https://xojo.com/issue/28113>) Note you must use it first then commit the “new baseline” changes, then use it again each time you re-open the project to re-establish the correct baseline, or at least use it before switching to your version control system to review and commit code…
// Fix VCS Gremlins.xojo_script (2013-2021 Jason Cox, see report 28113)
// Note you must use this script first and then commit the "baseline" of changes.
// There will likely be a lot of things changed, but this will become your "new normal" state.
// Then as you code in the future, as you see lots of garbage changes accumulate,
// simply run this script again and it will clear it all up before your next commit.
DoCommand("NewDocWindow")
dim windows() as string
CollectWindows("")
sub CollectWindows(path as string)
dim items() as string = Sublocations(path).split(chrb(9))
for each item as string in items
dim newPath as string = path+"."+item
if path = "" then newPath = item
location = newPath
select case TypeOfCurrentLocation
case "Folder"
CollectWindows(newPath)
case "Window"
windows.append newPath
end
next
end sub
for each name as string in windows
location = name
dim pv as string = name+".visible"
dim b as string = propertyValue(pv)
if b = "true" then
propertyValue(pv) = "False"
propertyValue(pv) = "True"
else
propertyValue(pv) = "True"
propertyValue(pv) = "False"
end
DoCommand("SaveFile") // FOR XOJO 2020r1+: We must save each time we toggle or nothing changes.
next
DoCommand("CloseWindow")Criticism is not antagonism. Besides… am I wrong?
When the criticism is constructive, please feel free to share it. Posting a criticism just to be critical does nothing to help anyone with this issue and only serves to create a toxic discussion.
If anyone would like to discuss constructive versus destructive criticism, I’m open to a private conversation. This thread is about the GIT issue and I have no problem locking it for going off the rails.
It is constructive criticism. We hear the excuse “it will be done when it’s done” far too often about far too many things.