Leaderboard

fixed too (same fix as for the Expert Manager) The reason was that I tried to avoid flicker when adjusting for DPI changes which had the side effect of prematurely showing that form during construction.

Given the simple code: type TMyClass = class end; procedure P; begin var obj := TMyClass.Create; obj.Free; end; Try to count, how many function calls (and especially virtual calls) are performed here. And after that, it's become clear that additional "inherited" call in destructor changes almost nothing.

The new High DPI Form Designer in Delphi gives you the following choices: Low DPI (96) default Auto DPI FIxed DPI Choice sounds good, however none of the choices is satisfactory: Working with the Low DPI setting in a High DPI monitor is next to impossible given the minute size of the form. Auto DPI is the version control nightmare. If you have different developers working with different screen resolutions, or even one developer working on say sometimes on a desktop with a DPI 96 and sometimes on a high DPI laptop, every time you touch the form on a machine with a different resolution all the coordinates widths and heights of the components will change. Absolutely no go. Fixed DPI has the same issues as Low DPI. You set the Fixed DPI to match one of the screen resolution, but when you open the form to another computer the form will show either too big or too small. What I would like to have is Fixed DPI, so that you avoid the version control issues, but automatic scaling of the form into the Screen coordinates and back to the Fixed DPI when you save the form. I know that the scaling from one DPI to another and back may result in changes of the original values. But the scaling back to the Fixed DPI does not need to happen unless a control is moved or resized. Is it just me that have issues with High-DPI designer? @Marco Cantu @David Millington Your comments will be appreciated.

Have you considered blogging?

I can imagine the bug reports when some day TObject.Destroy actually gets some code and no one will remembers this oversight.

This question is basically like asking why TButton(ListBox) fails when ListBox is a TListBox. That's directly analagous to your cast.

The most common way do text-processing in Delphi is to load a file into a TStringList and then process the text line-by-line. Often you need to save the contents of the StringList back to the file. The TStringList is one of the most widely used RTL classes. However there are a number of limitations discussed below: a) No easy way to preserve line breaks on Load/Save TStringList does not make any effort to recognize the type of line breaks (LF, CR or CRLF) in the files it opens, let alone save that for use on saving. b) Information loss without any warning or any option for dealing with that. Internally TStringList uses unicode strings, but when you save its contents to a file using the default encoding (ANSI), this may result in information loss, without getting any warning or having any means for dealing with that. TEncoding.GetBytes also suffers from that. c) No easy way to determine whether a file you loaded into a TStringList contained a BOM When you load a file (LoadFromFile method), the encoding of the file is stored but not the information about whether the file contained a BOM or not. The WriteBOM property is only used when you save a file. d) Last but not least, no easy way of dealing with utf8 encoded files without a BOM The default text file format in Linux systems, in Visual Studio Code and other editors, as well as in languages such as python 3 is utf8 without BOM. Reading such files with TStringList is problematic and can result in errors, because it thinks such files are ANSI encoded. You could change the DefaultEncoding to utf8, but then you get errors when you read ansi files. No effort is made to detect whether a file without a BOM contains utf8 sequences. Overall, it is desirable that, when you load a file using LoadFromFile and then you save it using SavetoFile, the saved copy is identical to the original. I am attaching a general purpose TStringList descendent that deals with all the above issues in case anyone has a use for that. XStringList.pas

It is worse than that. It loads the entire file into a local byte array, then it decodes the entire byte array into a single Unicode string, and then it parses that string to extract the lines into individual substrings. So, by the time the TStringList has finished being populated, and before TStrings.LoadFrom...() actually exits, you could be using upwards of 4-5 times the original file size in memory! Granted, this is temporary, and all of that memory gets freed when LoadFrom...() finally exits. But there is small window where you have a LOT of memory allocated at one time.

You can do something similar using TStreamReader and its ReadLine() method, eg: var Stream := TReadOnlyCachedFileStream.Create('c:\temp\t'); try var Reader := TStreamReader.Create(Stream); try while not Reader.EndOfStream do begin S := Reader.ReadLine; // use S as needed... end; finally Reader.Free; end; finally Stream.Free; end;

I haven't confirmed it with Embarcadero but I heard they no longer have a bundling deal with CData. I looked into those connectors but decided against using them for licensing reasons. Look closely at the license for those bundled connectors. They are only allowed to be used for your internal software. If you redistribute your software to any third party you have to buy a full license from CData. OK so how much is a full license? Well for just one connector the price varies by connector but the Gmail connector for example is $799 per developer, per year. Now can you distribute to third parties with that license from CData? No you can't. That $799 connector can still only be used for internal use. So how can you distribute to anyone outside your company? The website says contact CData for further pricing. I didn't bother. Buying the full suite of connectors is somewhat more economical. You can get all their FireDAC connectors for $1999 but that's per developer, per year and still doesn't let you distribute software outside your own company. If they were $50 each and you could distribute them as you liked as with almost every other Delphi component I'd consider them. With their licensing as it stands today I find it very difficult to justify purchasing them. See here for the details from CData https://www.cdata.com/subscriptions/firedac/#faq