Leaderboard

A multiline string is multiline - simple as that.

The closing quotes dictate the alignment, lines inside the string thus cannot be more left than the closing quotes, the last line does not have a trailing line break, if you want a trailing line break, add an empty line

Not quite the implementation I would have liked though. Triple quotes '''? Who came up with that? Is that copyied from another programming language? I mean, Pascal is said to be very verbous, so why not somehing more explicit like: blub := multiline(' line1 line2, indented line3 '); People who don't like verbosity would complain of course, but these would complain about Pascal syntax anyway. (Goes away, silently weeping and anticipating yet another long night trying to adapt the GExperts Source Formatter to yet another string syntax ...)

I'm quite sure that the people at TIOBE are driven night and day by their intense feelings of envy towards Delphi. I really can't imagine they think about anything else.

Influenced by C# (like several features in Delphi have been): https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/proposals/csharp-11.0/raw-string-literal

What if you want a line with a single semi-colon inside the string literal? With the current implementation your example would be written this way: blub := ''' line1 line2, indented 3 spaces line3 '''; // the ending triple quotes are aligned with the no-indentation position Some background for this discussion: Raw string literal

I actually prefer the new syntax over the suggested one, as that is already occupied by a call to function multiline taking a string parameter - and fails because of the line-breaked string literal. Instead of teaching the compiler that a function call to multiline (what happens if I already have a similar named function in the scope?) to accept line breaks in the only sting literal parameter, the new syntax keeps the available parsers intact. They will just fail on the new multiline syntax as any Delphi compiler version before does. The new syntax is pretty simple to detect: This makes tweaking the parser not too complicated, as the start and end tokens are easy to recognize. While the triple quote alone resembles still valid syntax in previous versions, the mandatory new line would fail to parse. That is the condition where the new parser should intercept until the end condition is met. It still seems unclear how one has to escape a triple quote with no text preceding it inside a multiline string.

They heard my voice ;-)) https://blogs.embarcadero.com/yukon-beta-blog-delphi-language-modernizing-string-literals/

A huge thanks to David Nottage! A fix has been found and I've included below for those that need it. The changes need to be made in FMX.inAppPurchase.iOS.pas (copied into your own project first as usual). I've confirmed that this fixes the crash in iOS 17 and also still works in iOS 16. Not sure why we didn't see the crashes in iOS 16 but may be random luck given the nature of bugs like this. The same fix has been sent to EMB in the Quality Portal to hopefully include in the next update. procedure TiOSInAppPurchaseService.QueryProducts(const ProductIDs: TStrings); var ProductIDsArray: NSMutableArray; ProductIDsSet: NSSet; ProductID: string; begin //Check FProductsRequest isn't already in use if FProductsRequest <> nil then raise EIAPException.Create(SProductsRequestInProgress); ProductIDsArray := TNSMutableArray.Create; for ProductID in ProductIDs do ProductIDsArray.addObject(StringToID(ProductID)); // changed from the very poorly named PStrToNSStr to StringToID ProductIDsSet := TNSSet.Wrap(TNSSet.OCClass.setWithArray(ProductIDsArray)); FProductsRequest := TSKProductsRequest.Wrap(TSKProductsRequest.Alloc.initWithProductIdentifiers(ProductIDsSet)); // ProductIDsArray.release; -- comment these out to fix the issue // ProductIDsSet.release; -- comment these out to fix the issue FProductsRequest.setDelegate(FProductsRequestDelegate.GetObjectID); // calling GetObjectID without the redundant cast //Set off network activity indicator SetNetTrafficIndicator(True); //Now initiate the products request FProductsRequest.start; end;

Because they prohibit the formatter from concatenating the lines.

Actually I use these quite often. In the case of your SQL, which could as well come from the FireDAC query editor, I just copy the whole code, create a string array constant with a simple template, multi-paste the SQL and format the results: const cArr: TArray<string> = [ // 'SELECT', // 'DATE_FORMAT(co.order_date, ''%Y-%m'') AS order_month,', // 'DATE_FORMAT(co.order_date, ''%Y-%m-%d'') AS order_day,', // 'COUNT(DISTINCT co.order_id) AS num_orders,', // 'COUNT(ol.book_id) AS num_books,', // 'SUM(ol.price) AS total_price,', // 'SUM(COUNT(ol.book_id)) OVER (', // ' ORDER BY DATE_FORMAT(co.order_date, ''%Y-%m-%d'')', // ') AS running_total_num_books', // 'FROM cust_order co', // 'INNER JOIN order_line ol ON co.order_id = ol.order_id', // 'GROUP BY ', // ' DATE_FORMAT(co.order_date, ''%Y-%m''),', // ' DATE_FORMAT(co.order_date, ''%Y-%m-%d'')', // 'ORDER BY co.order_date ASC;', // '']; procedure UseSQL; begin var qry := TFDQuery.Create(nil); try qry.SQL.AddStrings(cArr); // ... finally qry.Free; end; end; The same scheme also works for JSON or XML. Interesting, that you bring up the SQL text, which is neatly split into multiple lines - probably for better readability. Despite allowing string constants with more than 255 characters in one line, it would be more helpful to have string constants over multiple lines preserving linefeeds. Then it wouldn't even matter if the lines are limited to 255 characters each, although I expect this limit being lifted anyway whenever such a feature will be implemented.

this list is a nonsense stuff and has nothing todo with Delphi.