Dalija Prasnikar

That is useful if you get paid by the LOC compiler generates-

There is another overload that takes Pointer... and it seems like this one is supposed to work with object instances, but it crashes instead.

It does not fail on private fields, but on retrieving type. You are passing object and GetType expects class GetType(AnObject.ClassType)

Delphi strings are pretty good as far as performance is concerned, TStringBuilder might have advantage when you need to handle longer strings and where benefits of preallocating buffer will outweigh the cost of the builder allocation, deallocation and try...finally block. I use TStringBuilder in few places, where it simplifies code, and I never measured the speed because it was not important in there. If you want to knock yourself out with micro-optimizations, you should definitely take a look at Knuth-Morris-Pratt algorithm, especially if you are matching same patterns over and over again https://en.wikipedia.org/wiki/Knuth–Morris–Pratt_algorithm

It seems that TStringBuilder is not quite as fast as it could be. I didn't gave it closer look, so I cannot say whether the issue is creating and destroying TStringBuilder or other TStringBuilder code.

Possible.

Initial idea that multiple scans are bad for performance is good, but your steps are wrong. You should scan the string for all substrings in one go, but you should also build new string while you are scanning. Using TStringBuilder or similar pattern with preallocated buffer would be appropriate. And when I sad scanning string for substrings, don't use Pos function. Scan string one character at the time and match it with patterns you are looking.

You don't need to uninstall 10.3 or older versions. 10.4 can coexist with them. Installer will probably recognize your existing license. And ask you if you want to use it. If it does not recognize it, they it will ask you for serial number and you will need to go through online activation process.

I am sorry if I misunderstood your point. You didn't explicitly said why are you suggesting passing TEvent instead of using global access and phrase "Don't forget" can be easily interpreted that if you use global objects directly, code will not work properly. At least that is how I have read it.

Not using global vars is good advice, but your particular advice here is wrong for several reasons. First, accessing global state (and changing it) is always a problem when it comes to thread safety, because one thread can change that state and interfere with the other using that same state. Think of global TFormatSettings variable. Having formatting functions that works directly with global setting is not thread safe because different threads can change settings as they please. On the other hands functions that use format settings passed as parameter are safe. But the crucial thing here is not passing as parameter alone, but what happens when you pass it in this particular case. TFormatSettings is a record and when you pass it as parameter function will get a local copy of the whole record. That is what it makes it safe. When you pass object instance as parameter, function will not get local copy of the object, just the reference. If the object is not thread safe and does not implement thread safety (synchronization) mechanisms that would allow safe access from multiple threads, then using parameter or global object directly is equally bad, and will not work. However, when it comes to synchronization objects, including TEvent, their whole purpose is to be shared between multiple threads. And if you need to orchestrate threads on application level, the only way you can do that is through global object. Yes, you can still write code in such manner that it does not access global object directly, but that code will not be "more thread safe", but more flexible and allows you to pass different TEvent instances to different threads that may have different purpose and possible different synchronization events. Using global locks, events and other synchronization objects is perfectly fine.

NNTP forums were the only ones that were really used. They were not shut down and deleted on a whim, but because of software and database problems. Posts were purged in attempts to stabilize and salvage the forums, but failures keep happening. During that time Embarcadero created new web only forums, but they were never extensively used - I am not going to analyze why.... Well, now you have Delphi Praxis for that. Old forums as such may be lost, but community is not. Many people are here and that is all that matters.

I just had to do it... Go with the flow! It's the Black Friday / Cyber Monday "season", so I had to rush the book offer The book was actually scheduled for release in early December, but then the Black Friday deals started popping up all over the place... pressure was building... and I finally caved in! I cut the darn thing in two, and decided to offer Part I at a discount, and will give Part II for free to all Buyers. Not really a 97% BF discount but hey... Junior is still studying, and we still have to pay the bills (Corona doesn't help, either)! So, here it is! I hope you'll like it like you did Delphi Memory Management! https://dalija.prasnikar.info/delphiebap/index.html Thank you all for the support!

Depends on the algorithm. Also, to use parallel for you will need to rewrite that algorithm to be parallel friendly. From your description, your algorithm is probably not suitable, if each step, depends on the previous step result. https://softwareengineering.stackexchange.com/q/238729/161734

There are two separate things here. VCL and VCL Styles. You said that VCL is being abandoned by Embarcadero and that is simply not true as there is a huge difference between "not receiving too many features" and being abandoned. Also by "not receiving too many features" I definitely didn't want to say it barely received any. There were numerous features introduced in VCL since XE2, some were VCL only, some were both VCL and FMX. The part with bugs and IDE and "overnight fixing" is strictly related to VCL Styles. Only introducing styles to IDE exposed how buggy they really are and how much fixing they need. And that amount of fixes cannot be made overnight. VCL is mature framework. I never said that for VCL Styles. VCL Styles were never mature, they are just feature that was never properly finished in the first place. I hope this is more clear now.

I opened new thread for more general discussion about VCL and VCL Styles

You are describing bad web page (I know there are plenty of those in the wild). This is not how web pages should behave 🙂 Nor any other GUI... In general, most mobile designs have some kind of scrollable container as root and then you adapt your content to fit the screen width, and what does not fit, you wrap it around. Additionally, you can have some fixed top or bottom bar for navigation. Only the simplest screens with just few controls, can avoid scroll bar.

I am afraid that your wishes are not aligned with reality. Unless you write your application for specific customer, targeting specific devices (screen sizes), your layouts will need to be dynamically adjustable. Like @Rollo62 said, this is mission impossible with zillion devices on the market. I think that using different form size layouts will only make things more complicated, than adjusting layout at runtime, even if you need to tweak it through code.

This sounds awfully familiar with this issue https://quality.embarcadero.com/browse/RSP-33140 But this issue shows when VCL Styles are used. Maybe something else got broken...

If you are not dropping components on the form, then it is better that you pass nil as owner. That way you can use those components in background threads (please note that not all components are thread safe and can be used in the background, but in this case we are talking about Indy). Which is generally preferable when you are doing any kind of network operations. Having multiple try...finally blocks kills readability, so I prefer using only one. You need initialize references to nil, to avoid issues if construction fails somewhere in the middle and finally might call uninitialized pointer. IdSMTP1 := nil; IdMessage1 := nil; IdSSLIOHandlerSocketOpenSSL1 := TIdSSLIOHandlerSocketOpenSSL.Create(nil); try IdSMTP1 := TIdSMTP.Create(nil); IdMessage1 := TIdMessage.Create(nil); ... finally IdSSLIOHandlerSocketOpenSSL1.Free; IdSMTP1.Free; IdMessage1.Free; end;

Brushes like other GDI objects need to be protected when shared between threads https://docs.microsoft.com/en-us/windows/win32/procthread/multiple-threads-and-gdi-objects I never worked with brushes in the background, so don't know exactly how you should protect it. Answer is somewhere in Vcl.Graphics unit.

Apple does not value backward compatibility as much as Microsoft. They make breaking changes a lot, either in OS or their toolchain and that causes various issues. Some issues break application building process, some break applications.

Flash is not absolute requirement, but it is necessary for viewing interactive content when you generate modeling documentation. Still, it is obsolete technology and should be removed. https://quality.embarcadero.com/browse/RSP-32771

Well, if nobody reports issues, chances they will be fixed is zero to none. Yes, there is always chance that EMBT developers themselves will eventually bump into the issue and make internal report, but those chances are rather slim. I am not judging anyone here, reporting bugs takes time, but the more people report reproducible bugs they encounter, the less bugs there will be out in the wild. Yes, I also know that report alone does not mean that bug will be promptly fixed.

Is there a bug report?

What is the solution? You cannot leave us like that, hanging in the air...