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
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.
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’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).
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.