Uwe Raabe

It seems to use whatever you put into the format string. My expectation was that it replaces the dot with the current DecimalSeparator, which would be logical as secs/msecs are decimals, but that isn't the case. After some searching I wasn't able to find some docs for milliseconds in local time formats. There are only international norms. I suggest to file a bug report and see what they have to say about it.

I found that the other way round it uses a dot when formatting the milliseconds. So either way is obviously wrong.

BTW, if you find the current behavior is wrong, please file a bug report. Otherwise the chances of changing it are pretty low.

Actually I don't know the rules. You can always pass a FormatSettings parameter fitting your needs.

Why is that nonsense? It is probably used to get the MSec part.

That may indeed be possible, but will probably turn out a bit tedious. It also doesn't have the flexibility to choose between both options. A more simple way could be to edit the compatibility settings for bds.exe and force high dpi support to one of the System values, but that also misses the flexibility. My personal favorite are the mentioned desktop links. Not only does it allow to quickly start Delphi in the desired mode, also dragging a Delphi file onto one of those also opens the file with the appropriate settings. Besides the dpi selection, I use this scheme for quite a while to handle different registry keys for Delphi.

You can do that with the command line parameter "/highdpi:unaware". That won't work with just a double click from Explorer, though. I have different links on my desktop to quickly choose between both behaviors.

I didn't say you need no query - you don't need the array.

Why the array? What hinders you to iterate through the dataset directly? Besides being easier it also avoids the memory problem when copying the complete query result into an array.

This behavior exists for quite some versions and is usually bound to the Application.MainFormOnTaskbar := True; command in the project file.

IIRC, the compiler emits a warning W1010 Method 'Create' hides virtual method of base type 'TComponent' for a construct like this: type TMyCom = class(TComponent) public constructor Create; end; That seems sufficient to fix the bug before the component is even registered in the IDE.

The former one. I was pretty sure I made that public a while ago, so that may indeed fall under the dream thing.

No: https://github.com/UweRaabe/CompressPath

Also this list from Darian Miller may give a rough overview: Delphi Master Release List

I use my build VM for that. It has Delphi versions 5, 7, D2007 up to 11 installed side by side and there still is plenty of room for more. When someday it will run out of disk space I can simply extend that. BTW, having all versions on the same machine simplifies multi-version builds a lot. My working environment is different, though. There I have several VMs for each of my customers to avoid problems with different needs and security. The Delphi versions on those may change during time. The physical host is reserved for my own projects and has only Delphi versions 10 to 11 installed. Usually it is cleaned after some years - latest when the hardware changes.

The Alexandria Wiki page has links to Previous Versions on the left.

Ate least I cannot reproduce.

This can also be a side effect of installing some design time package.

Perhaps this may help a bit: Azure DevOps and Delphi – Build Agents

Because they prohibit the formatter from concatenating the lines.

Isn't that what I just wrote?

The interesting part would be the declaration of PanelResize in the base class.

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.

You probably meant w := Use.When<Word>(Cond, 1, 32000);

In fact they are: type TStringArr = array of string; const cStringArr: TStringArr = ['Hello', 'World']; Just not with the record element type, because the record constants are not accepted as true constants.