Just checked out a project onto a new macOS system, loaded up 19r3.1, installed my plugins, reset my licenses so I could build on the new system, made one spelling error change in a module, saved - and I now have 132 changed files …
They are all the quoting issues - “True” is now True, 2 is now “2” …
[code]$ cvs diff M Dialogs/WCatalogFields.xojo_window
Index: Dialogs/WCatalogFields.xojo_window
Since this was going to be a new branch, using these changed files as the starting point has become a serious time-expense issue.
We have been dealing with and reporting this issue for years and it’s still happening. Why do these values keep flip-flopping - even in the same version of Xojo on the same platform?
The problem lies in the fact that the IDE stores properties of control instances in Variants and in certain circumstances it cant tell whether it needs to save the value as a string or as the type its supposed to be. We narrow one of these down from time to time (since only certain properties have this behavior) and get them fixed, but the issue is hardly ever in the same place.
Here’s my case on the issue, with very reproducible steps and probably the best - yet most annoying - workaround you’ll find. <https://xojo.com/issue/58751>
This really isnt something you can or should tar & feather Greg for
A lot of the design decisions about the formats predated his, and my, arrival at Xojo Inc
And they are a bugger to fix completely
EDIT : FWIW I also experience this and know why it is what it is and … yeah it sucks
Nothing personal Greg, but we dont really care what the cause is - we just want it fixed. The problem has been around long enough to give Xojo inc. time to address the underlying causes. It seems this is another example (like the many other issues with the IDE and framework) where important stuff gets constantly overlooked for stuff that Xojo thinks we need.
It matters. Very very seldom I need to track some changes from long long ago. It’s quite a difference if I have to check a couple of classes or over 100.
It’s all about your use case. My team manages millions of lines of C, C++, TCL/TK, Python, Java, ASM, and RB/Xojo code dating from as far back as 1985. Something like this is a tripwire and can result in tens of hours of lost productivity down the line if it’s not caught.
I just love responses that start with Nothing personal but… you make it sound like we dont want this extremely annoying bug fixed too.
As Norman said, its a design flaw that predates both he and I even working at Xojo and now both of us have tried to fix it several times over, with my most recent attempt being about 6 weeks ago. The problem is that any fix comes with the requirement of it cant break the IDE or any user projects and so far thats exactly what theyve all done.
Sad part is that the surest sign that weve fixed this issue will be when you dont notice it any more, kinda like fixing a squeaky fan belt in your car.
Maybe i do not understand, but we talk about saving values into a Text File. Couldn’t these always simply be saved with surrounding “” ? I mean; the IDE “knows” which value will go where and so it should know that “True” is the same as True, or?
But how would you store Data into a plain txt file? Take a CSV file for example. Everything you store will be plain text and to make sure each “filed” is “clearly” separated from each other field, you would surround those fields by a delimiter. Later when you read the data from this CSV file, your code knows how to deal with these fields. Like the field “TabStop”, it will always be a boolean value and never a String value (in the IDE).
Not necessarily. Order of item in the project matters. If your project item “ChildWindow” loads before its super “ParentWindow” then the IDE has no idea what it is yet.
Which is getting us back to the “there’s no simply about this.” The IDE would essentially need to load the project items - or at least the supers - sort them according to parent-child order, then load again. It’s no easy task.
