luebbe 26 Posted April 9 (edited) Hi Folks, I've come across a strange bug with string literals in Delphi. I am in the process of moving from Delphi 11.3 to 12.1 and suddenly one of our tests fails. I could narrow it down to a combination of the less equal or greater equal unicode characters in combination with a tab in the string. Here's the definition: const cExpected: array [0 .. 4] of string = ( '1 Line with <= and no tab', '2 Line with ≤ and no tab', #9'3 Line with ≤ and a', #9'4 Line with ≥ and a tab', #9'5 Line with >= and a tab'); On the left side of the screenshot is the result of the misinterpretation. You see that somehow the first characters of the last line that didn't contain a tab *and* a greater equal/less equal character overwrite the first characters of the lines that contain both. I've never seen this before. Does anyone have an idea what is going on here? Delphi 11 handled it correctly. Originally it was one const separated by sLineBreak instead of a const array of string. This combination also damages TestCase() Attributes in DUnitX. They also get misinterpreted. Edited April 9 by luebbe Share this post Link to post
Uwe Raabe 2064 Posted April 9 Could be related to String with non-ASCII characters directly attached to a #xx or #$xx literal corrupts the final string Current workaround is to use a + operator to concatenate the parts. 3 Share this post Link to post
Cristian Peța 107 Posted April 9 @Uwe Raabe do I need to do something more than login to see the report? Share this post Link to post
luebbe 26 Posted April 9 12 minutes ago, Uwe Raabe said: Could be related to String with non-ASCII characters directly attached to a #xx or #$xx literal corrupts the final string Current workaround is to use a + operator to concatenate the parts. In fact that's what I did. I concatenated the tabs with "+ #9 +" since they separate the string anyway. Thanks for the hint. Share this post Link to post
Uwe Raabe 2064 Posted April 9 37 minutes ago, Cristian Peța said: do I need to do something more than login to see the report? Either wait that someone adds you to the Embarcadero Customers group or file an issue by yourself, which automatically adds you to the group. Share this post Link to post
Anders Melander 1815 Posted April 9 42 minutes ago, Uwe Raabe said: Could be related to String with non-ASCII characters directly attached to a #xx or #$xx literal corrupts the final string Current workaround is to use a + operator to concatenate the parts. Ouch! I use that a lot. 9182 occurrences in the project I'm working on right now. I guess that just aborted our migration to Delphi 12 - again. Share this post Link to post
luebbe 26 Posted April 9 16 minutes ago, Anders Melander said: Ouch! I use that a lot. 9182 occurrences in the project I'm working on right now. I guess that just aborted our migration to Delphi 12 - again. Only about 500 for me. After I knew what was going on, I replaced them all. A systematic search & destroy did the job for me. Share this post Link to post
Die Holländer 49 Posted April 9 1 hour ago, Cristian Peța said: @Uwe Raabe do I need to do something more than login to see the report? If you just did a first login then you have to wait some time before you can see reports... Share this post Link to post
luebbe 26 Posted April 9 4 hours ago, Uwe Raabe said: Either wait that someone adds you to the Embarcadero Customers group or file an issue by yourself, which automatically adds you to the group. Still waiting (and hoping) Share this post Link to post
Lars Fosdal 1793 Posted April 9 The problem even shows up in the IDE. and the cure is the same as for compiled code 2 Share this post Link to post
JonRobertson 72 Posted April 9 9 hours ago, Anders Melander said: I guess that just aborted our migration to Delphi 12 - again For me as well. Although I planned to wait until the end of April just to see the feedback on 12.1 before I started. Share this post Link to post
Sherlock 663 Posted April 10 Sometimes I'm thankful for my ignorance. I didn't even know it was possible to concatenate without the +. Otherwise I would be in Anders' position and screaming bloody murder. Share this post Link to post
Attila Kovacs 631 Posted April 10 1 minute ago, Sherlock said: Sometimes I'm thankful for my ignorance. I didn't even know it was possible to concatenate without the +. Otherwise I would be in Anders' position and screaming bloody murder. question is, if dfm's are affected too Share this post Link to post
Lars Fosdal 1793 Posted April 10 16 minutes ago, Attila Kovacs said: if dfm's are affected too You can't really declare strings in .dfms as 'Text'#32'Text', can you? If you set a caption or label in a dfm from such a string in code, yes you'd be affected. Share this post Link to post
Lajos Juhász 295 Posted April 10 3 minutes ago, Lars Fosdal said: You can't really declare strings in .dfms as 'Text'#32'Text', can you? The ide will generate object Label1: TLabel Left = 303 Top = 233 Width = 99 Height = 15 Caption = #1058#1086' '#1073#1077' '#1086#1088' '#1085#1086#1090' '#1090#1086' '#1073#1077 end Share this post Link to post
Lars Fosdal 1793 Posted April 10 (edited) I should simply stop posting without actually checking shit... object Label1: TLabel Left = 303 Top = 233 Width = 99 Height = 15 Caption = 'Text'#32'Text' end does however, work correctly. Edit But if you actually edited the dfm text and put in that #32, then view as form, and back to view as text - it has been converted to 'Text Text'. As @Lajos Juhászpoints out - Unicode text that is entered in the form attribute editor, will translate to #1234 values. Edited April 10 by Lars Fosdal flogging the wrong dead horse again 1 Share this post Link to post
Sherlock 663 Posted April 10 1 minute ago, Lars Fosdal said: I should simply stop posting without actually checking shit... Now where would be the fun in that? 2 Share this post Link to post
msohn 28 Posted April 10 1 hour ago, Lars Fosdal said: But if you actually edited the dfm text and put in that #32, then view as form, and back to view as text - it has been converted to 'Text Text'. As @Lajos Juhászpoints out - Unicode text that is entered in the form attribute editor, will translate to #1234 values. Not only unicode. Everything below space and above 127, i.e. ASCII minus the non-printable ones. System.Classes.ObjectBinaryToText.ConvertValue has all the - not so glory - details. I'm surprised you're not used to encountering those - assuming Scandinavian background. I see those fairly often in DFMs because of German umlauts - for projects not designed in English. Share this post Link to post
Lars Fosdal 1793 Posted April 10 @msohn - I don't usually spend much time in the text format .dfm. Share this post Link to post
Remy Lebeau 1436 Posted April 12 On 4/9/2024 at 3:29 AM, Uwe Raabe said: Either wait that someone adds you to the Embarcadero Customers group or file an issue by yourself, which automatically adds you to the group. I reported the issue to Embarcadero privately and they are looking into it. 2 2 Share this post Link to post