Dalija Prasnikar

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

As long as your variable is some interface type, reference counting will be properly initialized and you don't have to worry about memory management of Support destroying your instance. Code @David Heffernan posted for calling Support function is better one than your example. But this was not the root cause of your problems. You can also disable reference counting mechanism with the code @Alexander Elagin posted. In this case you have to Free the instance when you are done, but there is another catch, you need to make sure that at that point you don't have any active interface references to your object because automatic _Release that compiler inserts after that interface reference goes out of scope will access already destroyed object instance - which can lead to a crash.

You are experiencing classic issue of "mixing objects and interfaces" Your TBaseFrame class has enabled reference counting and you are using it like normal class. You should store it in interface reference - fBaseFrame: IInterface (or whatever other interface type suits you the best) and you should not call Free on it (you cannot call it on interface, but point is that its memory will be automatically handled so you don't have to worry about it) https://dalijap.blogspot.com/2018/03/dont-mix-objects-and-interfaces.html

Is attention to details useful? Yes. But also context matters. How useful is rearranging the chairs on Titanic?

Gain with any messaging system is decoupling, so it makes sense to use it even if you make synchronous calls. But in multithreading scenarios, you need full fledged thread safe system capable of posting messages to a queue. In other words, asynchronous messaging. Anything else is just a crutch that can be used only in most simple scenarios.

Yes, it can be harder to track from where message originated, but synchronous executing will make your thread wait twiddling thumbs while code runs in the context of the main thread. That is why posting messages is preferred. Of course, everything depends on the particular application and code and whether you can afford performance drop or not.

How about http://docwiki.embarcadero.com/Libraries/Sydney/en/System.SyncObjs.TInterlocked.Exchange

You can call it whatever you like, but if the fact that MS didn't bother to update MDI window style to match their latest (now 5 years old) Windows 10 OS does not qualify as being deprecated, then I don't know what deprecated is. Also MS is spreading that FUD for the last 25 years...

In addition to what @David Heffernan said https://docs.microsoft.com/en-us/cpp/mfc/sdi-and-mdi?view=msvc-160

Me, too. But complexities often come with additional features. And often simple systems do not have all the needed features, so when you need them, you can either write your own thingy that only has features you need, or you can use existing more complex one that has features you need plus some more.

That is fine. Point is that System.Messaging is not thread safe. If you are writing multi-threaded application and you need to communicate using some messaging system, then System.Messaging will simply not work in such conditions. You can still use it to send messages to the main thread, but you need to synchronize messaging code, which is not always viable solution. In multithreaded applications, you will need thread safe messaging system that is also capable of posting messages to some message queue.

Relax, it was a joke 🙂

Somebody needs to make a good compiler first...

Me and my family are fine, now. Thanks!