Windows, Xojo 2020 2.1: Xojo is destroying the pasted line breaks causing damages.
My app was reading a large SQL sequence I wrote in VSCode and pasted into a String Constant property. It was damaging the database in the tests, and I didn’t have clue why as it works “outside” Xojo. After much research I found the weird Xojo bug, it was truncating the 0D0A line endings to just 0D and the SQL treats 0D as if it was a space, not a line break. So when it reached a comment like “-- this sets whatever…” it treated the rest of all lines as an ONE large comment ignoring all the remainder instructions.
Such behavior ONLY occurs with Xojo and no other apps, so it’s a Xojo bug.
Or am I missing some “special trick” to paste UTF-8 code AS IS into a Xojo Constant?
Xojo editfields (such as the constant editor) normalize line endings to 0D on both Mac and Windows (I don’t know about Linux). You could use ReplaceLineEndings to get EndOfLine.Windows back. But Jeff’s suggestion is better.
Well, seems a known bug. I know how to workaround it as you guys suggested, my dirt way was exactly Tim’s suggestion, but a string should behave like a bag of bytes and when receiving a “paste” it should be “raw”. I should even paste and store binary data into it, the contents of a small image for example, without damaging it (at least as default option).
I guess it won’t be serialized into the source code, but will be referenced and loaded unnecessarily at runtime, and people could damage the app if they delete such file, or even edit it changing my code.
Well, Thanks guys for the participation. I found a similar problem already discussed and ignored in the forum, so I also will just workaround the bug with the extra unnecessary reprocessing overhead until Xojo understands that the current way they do, is not the standard way, and needs to fix it.
FWIW, it can be spreading terrible silent fails in someone else’s apps. Like executing an SQL as Ok, but only half of it, like having a code like this into a Constant:
DELETE a_table WHERE a_field = 123;
-- Now let's log whatever
INSERT INTO LOG ... ;
You can use encodebase64 to get a string that you can use as a constant.
It will be embedded, so more or less not hackable.
It can contain CRLF and binary data.
And it only needs decodebase64() at the other end to use it.
To me
DELETE a_table WHERE a_field = 123;
-- Now let's log whatever
INSERT INTO LOG ... ;
is asking for trouble anyway.
Personally I would be having two strings
Jeff, with all respect, it’s standard SQL and professional way of doing it, documenting steps where and when necessary. There’s a reason for “–” to exist, there’s no reason to say it is problematic. It’s done everywhere, and must work even in Xojo too. "-- " must work as “SELECT”, no standard feature should break a code. And they don’t, in any other IDE. Why should I be permissive here?
Again, the “behind the scenes” unusual, not standard, stream modification Xojo is doing, is the culprit of breaking ANY content pasted into a Constant that clashes with the not standard rules Xojo has set there (converting bytes to 0x0D). I don’t expect pasting some binary stream into a Constant and Xojo modify some of those bytes too. Is it a Constant or not?
There’s a difference on not having a way of not letting people damage an app (if they break the app at load/init time as missing frameworks prerequisites, that’s ok) and opening a huge point of security exploitation that any 10 y/o kid could exploit and damage a database. That’s, let’s say, unacceptable.
I see this every day when pasting content into Excel, or pasting http://www.google.com into a document. Like this one. See what it did to my text? I didnt paste a hyperlink here. What you are seeing is a result of pasting text into a text editor. If it doesnt do what you want, you need a workaround or wait a long time for Xojo to consider changing how they do things. If the workarounds arent suitable for you, no problem here.
I write SQL all day long, and am well used to – as a comment line.
I just don’t use constants with several statements in them myself.
You paste SQL into the Xojo IDE as a string and then complain when it treats it like a string in the same way it would with any other pasted string. Why should the IDE know anything about SQL?
As this is (apparently) intended behavior, I wouldn’t call it a bug, nor would I want Xojo to change it. For most, if not all, of us, most of the time we don’t care about the line endings, and there is value in standardizing them. For the occasions that we do (and I’ve been there), Xojo provides tools like ReplaceLineEndings.
You should reread all I wrote. The Xojo Constant bug is not related to SQL, just found it in such case. But such case is worrisome due to the nature of potential horrible silent fails using the pointed SQL example case.
That’s the costly workaround I used, but newcomers will expect that the bytes they paste there will be EXACTLY what they pasted. Changing the contents behind the scenes is not an expected behavior. Removing correct line breaks (that should contain 0x0A in any current OS) and substituting those with space-like chars (0x0D) does not count as something standard, even if we consider those pasted bytes as a text.
I don’t agree this is the case: I, and I suspect many other programmers, are used to text being “special” and line-endings being auto converted in many situations (text editors, FTP, websites, etc.) I’m also used to this not always working correctly, requiring workarounds.
Perhaps the real bug is that the SQL you are using is finicky about requiring 0D0A – what is this, 1996?
And again, Constants aren’t “text”, they are what you define, and I defined, a string of bytes, where I have put in this case an utf-8 text, but it could be anything, and that anything should not “autochange” to any other value without my intervention. The CRC32 of what I paste there should be the CRC32 of what I’ll find there after, if I do not touch it.
Maybe we need ways of having 4 types of “paste” operations to cover all use cases, “Paste Raw” (untouched “char” bytes, my preferred for a default), “Paste text, Windows EOL” (line endings converted to 0d0a), “Paste text, Unix EOL” (convert to 0A EOL) and Paste text, CR EOL (0d EOL, legacy from very old Macs).
Probably because you don’t care about unnecessary post-processing of contents all the time eating processing power. I envy you, such “small things” reaches me strong as aberrations.
