Dalija Prasnikar

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...

What do you mean by Write CS and Read CS? The way I read it, it sounds like you have two critical sections protecting same data. You should have only one.

If the dictionary is populated before threads start using it, and you are not writing anything afterwards, then you can safely share that dictionary between threads for reading without any additional protection. If you will be writing to it while threads are running, then you need to protect all reads and all writes with some locking mechanism.

Logically, I would write libvlc_media_tracks_release( LTracksPtr, LCount ); You pass the LTracksPtr in ..._get function, so only logical thing to do would be to pass same pointer to ..._release function. But this is more logic than C... Strictly following the declarations, I would do the same you did in your non-working code.

Problem with quoting is that usually it is either cut down to the point of being misquoting or it requires more context to be properly understood. Knuth is spot on, and if you read more besides the "Premature optimization is root of all evil" phrase, it will be more clear to you what it really means. https://softwareengineering.stackexchange.com/questions/80084/is-premature-optimization-really-the-root-of-all-evil

In Croatia (and Yugoslavia before separation) Pascal was taught in schools and universities. There are still schools that have Pascal in their curriculum, but C and other languages are taking over. Whether or not Delphi was and is used somewhere, I don't know. I only have information that FPC is used in some schools. CE licenses makes Delphi more approachable, so it is possible that this will change for the better.

Final version of my eBook Delphi Event-based and Asynchronous Programming has been released - 291 pages. You can find more information and purchase option at: https://dalija.prasnikar.info/delphiebap/index.html Thanks to all of you who purchased the incomplete pre-release version (179 pages) of my eBook! After a minor delay, the full version is here! You can download it through the same PDF/epub/mobi links that you have received earlier from FastSpring via email. The subject line of that email message was: "Your Delphi Event-based and Asynchronous Programming - Part I Delivery Information". If you have any problems, feel free to contact me via the contact form on my site. Thanks again! Happy Holidays to you all!

When you click on the combo, it explains that link will take you to the eBook, page and after the eBook purchase you will then receive link for purchasing paperback edition with discount. I guess you missed that part 🙂

Paperback edition of the book has been released. There is 50% discount for paperback edition for everyone who buys eBook edition. If you have already purchased the eBook version, and wish to buy the paperback, you're also eligible for a 50% discount! You can find instructions at: https://dalija.prasnikar.info/delphiebap/index.html

There have been changes in Windows that required updates to the applications. For instance UAC introduced with Vista. Occasionally, there are also some other tweaks in Window that can cause some "minor" issues and require code update. It is that Microsoft has really great track record of providing compatibility options for older applications, so even very old applications can keep running. but this is more Windows feature than Delphi one. It helps that Delphi mostly relies on very stable core WinAPI, and that it creates single executable. But on other platforms Delphi apps don't have such longevity.

> There is no performance penalty here. You need to trigger reference counting when creating new instance. That is the original issue you are solving. You have misquoted me. I didn't say that original problem you are solving is performance, but that you should not worry about performance with using New because you cannot avoid initial reference counting trigger for reference counted instances. And original issue with const is that it does not trigger reference counting when creating object inplace. Performance comes to play, when you don't use const but in that case you don't have to bother using New either. Yes, there are other places where reference counting can bite you... but you can do whatever you like. Additional issue with 1. and 2. is that not all code is under your control. Education is the first thing you should do, regardless of other approaches. Keeping developers in "stupid" mode is never smart thing to do.

Yes. Since such coding pattern is not too common in Delphi because of its manual memory management. So you either cannot use it at all, or you are creating objects and passing ownership which is not the most common scenario, or you are creating reference counted instance where inplace creating creates problems. There is no performance penalty here. You need to trigger reference counting when creating new instance. That is the original issue you are solving. All you can do to prevent accidental misues is great, but sometimes people just need to use their brains and think what they are doing.

I wouldn't use any of those solutions. Because that is not golden rule. On the contrary, for reference counted types you would almost always use const to avoid unnecessary reference counting overheard. Problem is not in the method that has const, problem happens at call site. As such it should be handled at call site. First, handling it at call site allows you to trigger reference counting only for references that really need it, next, you will avoid situation where performance will become an issue and someone will go and change method signature according to common practice - using const and will inadvertently break code. Far better solutions than 1. or 2. are using additional variable instead of constructing instance during method call, This is also easy rule to remember - don't create anything inplace. Next solution would be explicitly typecasting TFoo.Create as IFoo And the last one, I like the most because it prevents you to make reference counting mistakes in other code, too, is to have class function that will create instance and return it as interface reference. As for finding all places where you can create possible problem and you need to fix it, simple search and replace can go a long way. For instance - if you have class function New, you can just replace TFoo.Create with TFoo.New and if have same parameter list, you are good.

I just voted.

Random errors like that suggest that some of your code is not thread safe and originating point of your problems may not be in the place where it finally blows up, but it gives you some hints to inspect your code that uses ThreadedQueue in broader context and possible code paths before you land on the error. Using different queue will not magically fix your problem, because problem is not in TThreadedQueue but in your code. You might get different behavior, and it might crash more often or not, but it will not be fixed until you find and fix real issue.

Yes, there is, but Delphi Praxis allows much broader questions than Stack Overflow. So, while debugging questions here and there require same amount of information, algorithms generally don't fall into same category. I don't think that asking for some pointers and ideas is somehow not welcome here. How does it relate with Delphi... well, obviously implementation would be in Delphi.

Question as asked like here would not pass on Stack Overflow.

Things changed since then... for some reason unknown to me StartsWith has been changed to the point it involves 10+ calls to other procedures, and eventually calls Windows API CompareString function. Since the final call handles case insensitive variant, it makes sense in that case (still too many indirect calls for my taste), but code path for case sensitive variant is just WHY, OH, WHY???? No wonder it is slower... I think the plain for loop comparing chars would do better...