Uwe Raabe

BTW, rebuilding with C#/.NET will cost a multiple of time and money with no real benefit but plenty of problems.

I guess, the application uses BDE components? These are indeed not very capable of this scenario. I suggest to replace these with FireDAC components, which should handle this out of the box or can easily be configured to do so. There are semi-automated tools to help with this replacement. There are other alternatives for replacement, but the BDE components are not suitable for this job unless you start to change the DB access behavior of the application.

Not sure about your use case, but FireDAC has some tricks to load only a specific number of records on open and fetch the following when necessary. There is also an option to fetch blobs for a record only when needed.

Looks like that is as designed. FItems in TListHelper has been a Pointer even in 10.2, but in 10.2 the TList holds FItems as array of T, while 10.3 doesn't have this anymore.

There are ways to bridle those.

Probably related: Bug in Delphi 10.3 Rio / C++Builder 10.3 ISO affects TMS installers

If you call it cyclical re-engineering cult, so then. I simply see it as a way to make things work smoothly for me. I see that time I invest here pays back pretty soon and thus is well spent, at least better than constantly lamenting over CodeInsight not working. Changing the compiler or CodeInsight itself is out of my reach and I am not going to wait for others to do so.

Not sure if that is a RAD thing. It is more a mixture of convenience and shortsightedness. Finding a clean and proper architecture is not an easy task. Often these projects are a result of short time and pressure and the lack of getting things right in the second go.

That indeed has a high impact. My projects are usually free from dependency cycles, but I cannot do much about third party libraries there. Nevertheless can I rarely see problems with Code Insight here. Also compiling is blazing fast and even a full build does not last much longer. In heavy contrast to a customer project I am just working on, where a Ctrl-Click needs seconds to minutes to return and code completion is more of a hindrance than of help. Also I have to re-build the whole project when I make a small change to the interface part of most of the units, because a simple compile won't succeed due to the cycles. I encourage everyone to eliminate those cycles as soon as possible. They cost you a huge amount of your time.

Wrong RSP number?

I have even been at the edge of dropping everything below 10.3 Rio at some point, but the effort to make it compile with the other 10.x versions was not that much (although it just turns out that there still might be some hickups with 10.2.0 to 10.2.2). After all, dropping support for older Delphi versions doesn't take anything away from existing users of these versions. They just won't get any new enhancements. The crucial point for myself is the testing effort for all these versions I don't use on a day by day basis. Given that these tests usually reveal some problems related to that version, that effort often rises significantly.

That is correct! With 10.3 there is no difference in TBytes and TByteDynArray. Both are TArray<Byte>. You can simply remove the TByteDynArray overload when compiling for 10.3.

The process of updating GetIt packages is just too clumsy to keep pace with new releases.

No, you have to add unit2 to the uses clause of unit3 manually. You might also be able to remove unit1 from the uses clause.

Can you give an example what you mean by "updated automatically" in this context?

The Owner is not necessarily the form. Sometimes the owner is a TFrame descendant or may even be nil. Iterating the Parent until a TCustomForm is found is usually the way to get the required form instance. Perhaps iterating until Parent is nil is another valid approach. That would also cover the case where one form is parented into another one.

You can also search the registry. The Package Cache key (like HKEY_CURRENT_USER\Software\Embarcadero\BDS\19.0\Package Cache) contains all installed packages with all its components.

Extend the record a bit and try again (so it doesn't fit into a register): TTestRec = record dummy: array[1..10] of Integer; Value: Integer; procedure Change( AValue: Integer ); end;

It is still possible to change the fields of a const record parameter when you use one of its own methods to do that.

Look at the different overloads of GetFiles and use that one matching your needs. If you have to specify TSearchOption.soAllDirectories you should specify that to the appropriate overload. files := TDirectory.GetFiles('C:\Temp\', TSearchOption.soAllDirectories, function(const Path: string; const SearchRec: TSearchRec): Boolean begin Result := TPath.MatchesPattern(SearchRec.Name, '*.exe') or TPath.MatchesPattern(SearchRec.Name, '*.dll'); end);

If you want only files use GetFiles. If you want only folders use GetDirectories. If you want both use GetFileSystemEntries. You don't need multiple calls - at least I can't imagine a use case for it in the moment. If you want all DLL and EXE files use the code I gave as an example. The Embarcadero example above selects the correct method to call depending on the given parameters - admitted in a somewhat weird way. It never calls more than one GetXXX method, because the three if-clauses are mutually exclusive. BTW, the loop to add the LList to the TStringlist can be replaced by a simple AddStrings call in recent Delphi versions. Also returning a TStringList instance as a function result is not a first class approach anyway. That's why all the IOUtils functions return string arrays.

TDirectory.GetFiles/GetDirectories/GetFileSystemEntries have overloads taking a TFilterPredicate. You can provide your own accept function with that. The following example lists all dll and exe files from the given folder in one go. files := TDirectory.GetFiles('C:\Temp\', function(const Path: string; const SearchRec: TSearchRec): Boolean begin Result := TPath.MatchesPattern(SearchRec.Name, '*.exe') or TPath.MatchesPattern(SearchRec.Name, '*.dll'); end);

You can even shorten the TURL.Create by introducing a function URL wrapping around that. This is similar to TRect.Create and Rect. As a drawback it somewhat litters your scope.

Project Magician has an option to strip all version info from child configurations. That way the values from the base (platform if you have non-Windows targets) configuration are effective. It doesn't hinder you to edit any child values, though - they just have no effect any more. https://www.uweraabe.de/Blog/2018/05/17/keep-your-project-files-clean-with-project-magician/

I guess you are referring to TDirectory.GetFiles here as TPath has no such functionality. Well, that is merely a wrapper for FindFirst/FindNext so not actually a new approach and such not worth investigating in terms of speed over convenience.