Unchanged files having changes continues to boil my backside ...

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

RCS file: /usr/local/cvs/Server_Console_207/Dialogs/WCatalogFields.xojo_window,v
retrieving revision 1.1.1.1
diff -r1.1.1.1 WCatalogFields.xojo_window
47c47
< TabStop = “True”

  TabStop         =   True[/code]

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?

But, yes, Web 2.0 is very important.

The problem lies in the fact that the IDE stores properties of control instances in Variants and in certain circumstances it can’t tell whether it needs to save the value as a string or as the type it’s 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. feedback://showreport?report_id=58751

@Greg O’Lone : Doesn’t that mean that the architecture is wrong?

Also, not only text projects are affected: feedback://showreport?report_id=57120 .

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 :frowning:

EDIT : FWIW I also experience this and know why it is what it is and … yeah it sucks

Nothing personal Greg, but we don’t 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.

I’ve noticed this too, but it doesn’t particularly bother me and I think there are more important things to worry about.

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 don’t want this extremely annoying bug fixed too.

As Norman said, it’s 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 can’t break the IDE or any user projects” and so far that’s exactly what they’ve all done.

Sad part is that the surest sign that we’ve fixed this issue will be when you don’t notice it any more, kinda like fixing a squeaky fan belt in your car.

But this is one of those issues that cost us time (read:money) and we do not have a real woraround for.

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?

I don’t have as much experience with the code as Greg and Norman, but I have enough experience to know that there’s no “simply” about this problem.

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

Why? How does the IDE know that should be a boolean while loading the project?

But the IDE knows which type it’s supposed to be when it reads the data, or? I mean, in which case would a Property “TabStop” be a Double? :slight_smile:

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.

Then this should be fixed too. :wink:

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.

Herein lies the crux of the misunderstanding - you ASSUME what the IDE knows & how it knows what it knows