You presume incorrectly. But this is something that benefits every user the overwhelming majority of time, and minimizing the performance hit to practically nothing is easy, now that you know what to expect.
3 Likes
How unexpected behaviors could benefit anyone?
Why not just not needing performance penalties?
Yep, now I know what to expect, how about the newcomers?
Again, I have a weird feeling when part of the community start to defend wrong behaviors just because they are used to. Looks like a kind of Stockholm Syndrome. 
All the time people points to a bug and 3 bug lovers come and say āI know a workaroundā, letās just forget it. 
This bugs me off. 
It is apparently intended behavior, so not a bug.
Well, they need to add the destructive behavior to the manual, Iāve not found it yet.
https://documentation.xojo.com/getting_started/using_the_ide/constant_editor.html
https://documentation.xojo.com/getting_started/using_the_xojo_language/modules.html#Adding_Constants
1 Like
I agree it should be documented. Please file feedback.
2 Likes
If I would file one, it would be asking for the correction of the wrong behavior. And that would sink to the great deep valley of the ignored FB requests. So, as I said in the solution post, Iāll just let it go wrong as usual, as @AlbertoD reported it in 2018 and also was ignored. Letās just be selfish and let others report again in the future until the community start to think about how wrong the current behavior is, and take some action towards a proper correction. In the future Iāll be quiet about the issue, I donāt care about it anymore. Let them break some apps. 
I wouldnāt want the current functionality to change as normalising line breaks means one less issue to worry about.
Stick the data in a file and read it as a binary stream if you donāt want Xojo to mess with it.
3 Likes
It is serialized into the source code as a true constant, unchanged. Your users will never see it as a separate file.
Pleaseā¦ I tested it. If you go to app exe location, resources folder, edit the readymix.txt file as proposed by Jeff, and change the found content to, for example, āDROP TABLE XXX;ā and run the app, the table will be erased. So, no, it will not be serialized and integrated, it will be referenced and loaded at runtime.
That could be true IF normalizing meant using the current system EOL or at least a true good fixed one, like LF, instead of CR (the current one), because CR potentially causes huge silent fails. And in a Text mode, not String mode. String mode should accept AS IS.
Guys, I gave up on fixing this problem. So rest in peace. Dear MVPs, close this thread please. All to be said about how wrong the current behavior is was said, suggestions to fix it were made. So letās just give up on the issue and let old users used to workaround it being satisfied.
Not a solution to your problem, but I had a similar experience when using Filezilla to download a TEXT file from an FTP Website to my computer - ODOA becomes just OD. No problems when downloading TEXT files using WinSCP
I have no problem, the IDE and future users have one.
Dear MVPs, close this thread, please. All to be said about how wrong the current behavior is was said, suggestions to fix it were made. So let me just give up on the issue and let old users used to workaround it being satisfied.
Hereās how Iād handle it:
- Move the constants to a module.
- Rename the problematic ones something like ākConstantRawā and make them private.
- Create corresponding string properties with the desired names, e.g., ākConstantā.
- Create an Init method thatās called from App.Open that copies the Raw constants with the corrected line endings to the corresponding properties.
Cons: These are no longer constants.
Pros: The performance hit will be minimal and only once at the start of the app, and code that uses the constants will not have to be changed (or changed much depending on how the original constants were referenced).
Kem, I have no interest in ugly, complex, time intensive to dev and runtime, workarounds for a proper āpasteā into a Constant. If wanted such, I could write myself some tool where I could paste in any content and receive a proper serialized string like kVar As String = "..."+ChrB(10)+"....."+ChrB(7)+"...'....""...xxx" that I could paste into some part of my code. My intention here was to help the community and Xojo, not myself. As a Most Valuable Moderator, please close this thread as I requested, please, as I see no intention in fixing the bug.
Not a ābugā.
Nothing will change without filing Feedback, as you know.
These threads are also for future readers who might benefit from various suggestions.
Closing a thread does not erase the contents. Just avoid more unusable noise not solving the bug. Calling a feature does not fix it. I know that the engineers have already read it, so thatās enough.
As the OP I DEMAND closing it, because I donāt intend to remove it.
@Dana_Brown, please, lock it. Other moderators seems rebel today. 
Hold on Rick, donāt lock the thread as others might want to chip into the conversation.
So I paste this into a constant called Untitled in the Windows ide (yes the last line is blank on purpose:
a
b
c
d
!
its stored as this in the project (yes the last pasted line went missing, bug?):
61 0D 0A 62 0D 0A 63 0D 0A 64 0D 0A 21
but when I use the following in code:
Dim a As string = Untitled
its somehow now:
61 0D 62 0D 63 0D 64 0D 21
so I actually have to use
Dim a As String = CType(Untitled, String).ReplaceLineEndings(EndOfLine.Windows)
to get my 0D 0A 'd string out of the ide that I pasted in there with 0D 0Aās ?
Is that a legacy issue because that just seems wrong?
I can go back into the IDE and copy the data back out of the textfield and paste it into a hex editor and it still contains the 0D 0Aās so its not been sanitised by the IDE, I even saved and reloaded the project and that still worked, so the data is in there correctly.