In some of my string properties’ default values, I require leading and trailing spaces. But the Xojo IDE erases them every time.
In fact one of them is supposed to be a string entirely composed of 10 spaces, but it ends up being a zero-length string.
Any way to turn this off so the IDE leaves the spaces alone like it does with Constants?
In the meantime, you might add known characters at the start and end of the string and strip them later. E.g. ❖My string❖
MessageBox TheString.ReplaceAll(“❖”,“”)
Not ideal, of course, but may be a workaround 
.
Why would you make a string property of whitespace when you can do the same in code?
I am participating in a 50-line code challenge. Per the judges, values assigned within the IDE’s GUI do not count against lines of code.
Oh, now that is totally something different.
Even MacOS dfo that: strip leading and anding space(s) when you paste to the Sherlock window (Search in the Finder)…
In which case, you should be able to use constants and put those into the default value fields.
That’s a BUG. User must be able to set ANY arbitrary value to a property and the IDE should not break it.
Open an issue report.
I also hate the wrong Xojo “constants”, I learned that Xojo also breaks them interfering in the pasted contents. I pasted lines ending with \n and the IDE destroyed them changing them silently by \r
Xojo IDE also clears the text from “strange values” (it ask if you want it to remove some “gremlins”—not the used word, but I completely forgot the word it use).
With permission they can make whatever you agree. We are discussing arbitrary and without consent changes.
He do that too (first part of the sentence).
I can’t understand that from what you wrote… but… whatever 
As the IDE is breaking his desired value removing leading and trailing spaces, he should reinsert such spaces, not remove them. So your idea is almost there, just replace the special char with " " instead of “”:
Property MyString As String = "@@@2 lines, one with Leading 3 spaces|and another having 4 trailing@@@@"
Var lines() As String = MyString.ReplaceAll("@"," ").Split("|") // extended example of string translation
I agree that this should be considered a bug, even if it’s intended behavior, the behavior should be consistent with the data entry for a constant.
@Greg_O I can use constants, but it’s inefficient when it comes to lines of code. With properties I can pass many of them byref into functions and change their value without needing to declare and assign intermediate variables.
Unfortunately after all these years, making a change like this would potentially break hundreds of projects
I can’t think how because the change will only be different for new strings.
But yes, I usually copy/paste things on String properties and expect start/end spaces to be removed, that will make my new String not work if, for any reason, I copy a number (for example) from a PDF and I didn’t see the last character is a space.
Such behavior does not exist in any text or hex editor, the contents are preserved as much as possible, the clean up, if any, is on you after; so you are expecting the unexpected. 
I concur.
But Xojo does this, so as I copy/paste I do into Xojo properties I expect to not have start/end spaces, if they change that behavior I will start having problems until I understand Xojo changed the behavior.
This forum does it too (remove spaces), for example:
screenshot of what I typed (space before and after):
Anyway, if there is no Issue created about this the behavior will not change (I doubt it will).
You are comparing bananas and oranges. If you have this string in the square brackets [ aa bb cc ]
If you write in Xojo this code
Var x As String = ""
And put the cursor in the middle of the quotes and paste, you’ll have:
Var x As String = " aa bb cc "
And not
Var x As String = "aa bb cc"
And the first one is the expected behavior we have in Visual Studio, Android Studio, etc Including Xojo
So the property mess is just an aberration never seen anywhere and needing a fix.