Leaderboard

There are many legacy projects which are still in active production. This volume offers approaches to refactoring and modernizing the code base without the need for complete redesign and rewrite. Evolution, not revolution. These are approaches well suited to the incremental revision of production code, as is usually the concern with a commercial product. Motivated by my own experience with legacy apps and the need to find a manageable approach to transforming a product in current production. On Amazon: https://www.amazon.com/dp/B0B2TY6ZZ4

The quick and lazy way to handle this is to turn off the Scaled property in all your forms but then all your controls will be really tiny when the Windows scaling is cranked up. What you'll need to do is change several aspects of your forms to gracefully rearrange themselves as heights and widths change. Notice I didn't say "re-design" your forms but it does take some work. Get to know the Align and Anchors properties first. Consider using container components that automatically rearrange components but keep them in their place like the TFlowPanel and TGridPanel. There are many other things you can do--a quick internet search will reveal many blog posts and articles over the years. Here's a good starting point: https://zarko-gajic.iz.hr/writing-and-enabling-delphi-application-to-support-high-dpi-displays-and-4k-screen-resolutions/

Start Delphi 11 (DPI Unaware) from your Window start menu

Thank you very much for the detailed tips! Ok, so I changed the code to: BASSLibraryHandle := LoadLibrary(PChar('libbass.so')); if BASSLibraryHandle = 0 then begin BASSLibraryHandle := SafeLoadLibrary(TPath.Combine(TPath.GetLibraryPath, 'libbass.so')); if BASSLibraryHandle = 0 then begin Showmessage('Error loading libbass.so.'); Exit; end; end; if BASSLibraryHandle <> 0 then begin @BASS_Init := GetProcAddress(BASSLibraryHandle, ('BASS_Init')); ... BTW. I downloaded the Skia4Delphi package a couple of weeks ago, seems very cool stuff. I did not have time to check it though, but seems professional. Thank you very much for helping with this issue!

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;