“TabStop” → TabStop
“True” → True
I’m pretty sure it worked for a single version, but it’s now broken again. Is it really worth creating a new feedback? Xojo 2020r2.1
Edit: Well, I created another feedback report <https://xojo.com/issue/63619>
<https://xojo.com/issue/58634>
<https://xojo.com/issue/58471>
<https://xojo.com/issue/49272>
<https://xojo.com/issue/15487>
<https://xojo.com/issue/62820>
<https://xojo.com/issue/28113>
<https://xojo.com/issue/10927>
We are well aware of the issue and as we find them, we fix them.
BTW - If there are open cases, there’s no need to create new ones.
Can you make this your #1 top priority, it’s a huge time waste to carefully merge all changes everytime in git. Thanks!
Lots of feedback reports with ‘Fixed and Verified’ as the Status.
While I agree this is an irritation, there are lots of issues that are much more important.
2020r2.1 is really bad about this. Just about any save makes around 90 modified files. Many of them in ViewProperties. Saving on Windows instead doesn’t produce the ViewProperties “problem” and actually cleans them out.
The big problem is not knowing what is right. I can’t trust the format knows what it’s doing. It’s always making nonsense decisions about how a project can be saved. I can’t tell if a behavior is intentional or a new bug.
My scripts to encourage the IDE to re-save each file are no longer effective enough in 2020r2. My latest technique to mitigate this is to open the project, analyze, save, open GitHub Desktop, uncheck every change, and leave it running. As I work on my project, actual changes will be automatically checked by GitHub Desktop. However this is not perfect as some new changes will remain unchecked, so I still need to do the song-and-dance of reviewing every single change in around a hundred files.
I don’t know how you guys deal with this. Geoff said you guys tend to just commit everything. This saving problem is absolutely my number one frustration with Xojo.
last i had over 1000+ changed lines that where mostly only changed properties from (i dropped all changes cause it was too much)
“True” to True
or xojo added:
index = -110030405060770
or xojo changed:
EditorType = “” to EditorType = “MultiLine” or something.
It costs hours of work just to review these changes, $$ = WORK = $$ so top priority for dev teams and probably the xojo dev team themselfs.
It would be nice to have xojo state what the wanted values are:
“True” or True (without the quotes for booleans)?
i’d say without the quotes would be best (saves data and reads better) but what if xojo was to go the other direction ? As @Thom_McGrath notes here, it’s unclear of how to best-prepare for this.
That said, JUST committing everything breaks projects (over and over again). You’d just have to miss a tiny thing and you can revert commits and handle it all over again.
I’ve been happily using binary format for years on my own work, but my company will be switching to using GitHub (and therefore project format) within the next month or so. Hearing these problems with 2020r2.1 is really unnerving. We don’t have the time or extra people to go through every change to fix this kind of stuff, if we can even detect it. My co-workers are already pushing me to ditch Xojo, so I’m in a bind here. Knowing that Xojo is fixing these issues is one thing, but without a new release of Xojo I honestly can’t recommend we move forward. I’d say this is my #1 top priority, absolutely.
This makes it a little easier to deal with:
As a test, I just modified all the methods in one of my modules (23 methods), and saved. Then I ran the app I use for versioning. This is Cornerstone (an older version since they went to a subscription model in more recent versions). Cornerstone uses subversion internally; it can show you old and new next to each other and you scroll them both together. That makes it very easy to ignore the trivial changes and scroll rapidly to the important changes.
What I did today led to one (1) change being flagged by Cornerstone. No silly changes at all. Although that might be because I examined no controls.
By the way, there was a long thread about this same topic some time in the last 12 months (IIRC), possibly last two years, with contributions from Greg and Norman. I recommend reading it, if you can find it. It explains what the issues are.
Greg says that, but in my experience, it isn’t true. I’m sure there are fixes being made to the format, but I can’t say any of them have affected me in a positive way. At least in 2019r3 I was able to run an IDE script to get the project back to a “pristine” state. I can no longer do that in 2020r2.
Yeah, this issue has been around for a long time. We’ve tried in the past to fix it. I’m not saying this is a simple “just fix it” problem. It’s not. But my sympathy can only go so far.
So to give some clarity here:
In 2020r2.1 we did make a change to the ViewBehavior properties so that all values are saved all the time. The IDE had been omitting values that it thought were the “default” value, but that prevents us from changing the default value in the future.
In terms of knowing what the actual changes were, let’s explore that for a minute. The real question here is “What did the user change?” and that’s trickier to figure out than you would think. While the large majority of changes are made by users, the IDE uses the same mechanism for making its own changes.
That said, we are working on this and we do have some ideas about how to fix it, They’re just not “easy”.
Thanks, Greg. I have this issue also, and appreciate the work.
A related issue is that backwards compatiblity has been fragile lately, e.g. Web2 Backwards Compatibility 2020R2 to earlier versions is fragile
Would it be possible for the IDE to have the concept of “aliases”?
Between 2020R1 and 2020R2, Web text fields had the property renamed from .Value to .Text. This change was migrated to the VCP format as well, which was a breaking change.
I think a better strategy would have been to not change the text project format, but simply have the IDE map the new/old property name upon loading/saving.
If you did this via lookups, it would then be pretty easy for future IDEs to keep a small table:
IDEVersion PropertyName NewIDEVersion NewPropertyName
2020R1 .Value 2020R2 .Text
which could be used on-the-fly for loading/saving.
Well Most properties actually didn’t change they get mangled between loading and saving.
Say i load a xojo project that has a value of “True” (property) when loaded, now if i save it becomes True (without quotes). This is not a user change since when reading the project (file) properties if it contains quotes change it to unquoted (only) just never save boolean properties as “True” anymore?
Project loading (no problem):
“True” --> read by ide, all is ok
True --> read by ide all is ok
Project save (the problem):
some controls get “True”/“False” others get True/False (without quotes)
other controls stay True/False (without quotes)
The problem is here that it seems somewhere there is something like:
Var aBoolStr As String = """" + BooleanValue.ToString + """"
while something like this shoud be done:
Var aBoolStr As String = BooleanValue.ToString
I’m not say what’s actually happening but just suggesting what output we get in the saved files. It’s inconsisten, not always the same (looks like it’s depending on the control?) maybe a it’s not a single function but multiple different that are handling the save output?
That would solve 90% of all commit changes made by the IDE. since over 90% of the unwanted changes are from “True” to True and back. If it was only 1 way there wouldn’t be a problem?
I’ll check it out, thank you!
Not exactly. It’s more similar to
Select Case Value.Type
Case Variant.TypeBoolean
Return If(Value.BooleanValue, "True", "False")
Case Variant.TypeString
Return """" + Value.StringValue + """"
End Select
With more cases for other types of course. Variants are easily confused, and remember that the files are read from disk as strings. The IDE uses its knowledge of the properties to figure out how to parse them, since the text format doesn’t strongly type the values.
Just to reiterate though, I haven’t worked on the IDE on nearly 8 years, and even when I did, Norman handled the file saving stuff. So there’s plenty of room for me to be wrong here, but this is what I can remember about the issue.
Ahh i see. Well than the same could apply here. Since “True” is probably somehow parsed different than True and vice versa…
Say if it was a class interface doing the read then it could even be that every method is slightly different.
Well i hope a fix would come sooner rather than later… less clutter the better in the commits
You know, I should add a feature to gitmas to stage all code where the only change is the addition (or subtraction) of two quotes.