Since we can’t seem to stay on topic, I’ve locked this thread. If you wish to discuss further, please feel free to message me personally, or you can send an email to hello@xojo.com if you would like further information.
This has already been asked and answered.
The reason Greg is getting frustrated is that he’s made the point and people either miss it or selectively ignore it:
So both of Jason’s suggestions are a waste of time as they will nuke any property a USER makes called for example TabStop if they are the wrong type.
C’mon everyone, the IDE isn’t Mickey Mouse stuff, its really a quite complex system that has unfortunately though no singles persons fault has had massive feature creep over the years.
Well I was thinking the filter could be limited to the part of the file where Xojo’s own properties live – not filter within the user’s code portion of each file.
Also I’ve also long wondered if the IDE Script trick I posted of toggling on/off a single property value per window might point to the culprit. Since the correct baseline values can be established after initial loading of the project by running this script, and the issue won’t return while the project is open (one reason I avoid ever closing my main project for days or weeks), I suspect the core bug is located in the IDE code that handles opening the Text Project – not in the saving part.
So now you need another system to track all xojo created properties and engineers in the future need to remember to add their new stuff to that or you’re back to square one and you need to put in another post processor to catch those… ad infinitum
Well I said it was a temporary patch, a band-aid while the true fix is worked on. Plus it only needs to filter the problem properties we see flip the most: TabStop, TabIndex, AllowAutoDeactivate, etc. Sure, others can be added to the temporary patch, if they show up over time – But hopefully before too long the core bug will be discovered and fixed.