Dalija Prasnikar

Thanks! I will try to add some. I will need some time to prepare some meaningful examples that can show potential use cases. Event bus is a messaging system. Delphi already has basic event bus implementation in System.Messaging https://docwiki.embarcadero.com/CodeExamples/Alexandria/en/System.Messaging_(Delphi) You can also look at the examples there as those use cases apply to my event bus, too. Main difference is that System.Messaging is not thread-safe and you can only use it to send messages in the context of the main thread. If you want to send messages across multiple threads you need a thread-safe event bus, like NX Horizon. Because, it is thread-safe, it also has some additional features like dispatching events (messages) asynchronously in the background thread. Maybe the easies way to explain what is event bus is comparing it to a Button OnClick event handler. When user clicks a button code in the OnClick event handler will run. main difference (besides multithreading support) is that with button and its event handler there is usually deeper connection and there is direct link with the button and its event handler. For instance if you click Help button on some form, you would want to open Help window from its OnClick event handler. But in that case your form with button needs to know about help form. If you have many forms that need to open help form will create tight coupling between all those forms and help form. With event bus, you can declare TOpenHelp event type and then you can subscribe some code to such event type. In your forms with help buttons, you would still need OnClick event handler, but instead of directly opening help form from that OnClick event you can send a message to event bus that TOpenHelp event happened. And then subscribers to that event (there can be more than one) will receive it and run the appropriate code in associated subscription event handler. This way your forms don't need to know about your help form, and code handling your help form does not need to know from where TOpenHelp came from. Event type also serves two purposes. Its type tells that particular event happened, and its content (event can be any automatically managed or value type) is used to pass additional data. for instance if the TOpenHelp is integer type, you use it to store and pass help page number depending on which help button is clicked and then you can open help on particular help page. Another example would be downloading some files in the background thread and then sending TDownloadCompleted event from that thread with some data about particular download and then subscribers can handle and do whatever they need to do with that data. Process it further, show it to the user, or anything else.

Thanks! There are few reasons why they are not implemented as of now. First, I wrote this for my own needs and in my code I used regular methods, so I didn't had immediate need for anonymous methods. Next, I wrote about this event bus in my recent book Delphi Thread Safety Pattern, so I wanted to keep code as minimal as possible and focused on bus itself. Anonymous methods are definitely one of the potential future enhancements, but I wanted to publish the code as soon as possible instead of waiting to polish it more as this might have postponed release indefinitely.

Hi, I have just released new book: Delphi Thread Safety Patterns. https://dalija.prasnikar.info/delphitspatt/ It is on promotional sale until June,14. You can use Coupon Code: DTSPATT10 at checkout to get a $10 discount. At the moment there are two options: you can purchase eBook only or bundle: eBook and paper edition (those are separate purchases that go through different sellers and you will receive instructions for paper book with the eBook order). Paper book only on the Amazon is not available for the time being. Thank you all for the support!

Are you sure it is executed in the context of the main thread? Because that is not what the stack trace says. It shows it is called from within TOutThread.Execute method. Anyway, whatever the problem is, there is not enough code to determine what is the root cause. Data modules can be constructed in the background threads, but only and only if all components used are thread safe in that regard. In other words if they support being constructed in background thread. How they are configured and what other components are linked as properties also impacts the thread safety. Additional comment. That application does not have memory leaks is good, but not having memory leaks does not mean that code is thread-safe and that it will run correctly.

Being reserved word only means that you cannot use those words as identifiers. It does not tell you anything what each reserved word represents in the language. If you are asking about coding style and why is string written in small caps, then being reserved word has a meaning in that context because there is a coding style rule (which you don't have to follow, of course) that says reserved words are written in small caps. When you are talking about string being an alias for UnicodeString then this describes its semantic - its behavior and what it represents. "string" describes default string type and its definition can change in different compilers. For instance, in Delphi 1 string was alias to ShortString, and in Delphi 2 - Delphi 2007 it was alias for AnsiString, and since Delphi 2009 string is alias for UnicodeString.

In Delphi string is separate data type and strings are not classes https://docwiki.embarcadero.com/RADStudio/Alexandria/en/String_Types_(Delphi) https://docwiki.embarcadero.com/RADStudio/Sydney/en/Fundamental_Syntactic_Elements_(Delphi)#Reserved_Words

If you follow a guideline that all reserved words (keywords) are written in small caps, then string which is a keyword should be written as "string".

QP report already exists https://quality.embarcadero.com/browse/RSP-34349

Executing method on nil reference is actually a language feature. But such method must be static and you must not access any instance fields if instance is nil. One such method is TObject.Free that can be safely called on nil reference, because it checks whether object is nil before calling other code, in this case virtual destructor that cannot be executed on nil instance. procedure TObject.Free; begin if Self <> nil then Destroy; end; Additional explanation how static method dispatching works can be found here https://dalijap.blogspot.com/2021/07/virtual-methods-in-delphi.html

That is what I meant when I said all. We are on the same page here. That explains why I haven't bumped into that issue as I changed background settings for more than single theme, but I didn't do that all at once and changes were properly saved.

Hm.... it works for me. But there have been some glitches in saving various setting changes Since version 11. Saving same settings will randomly fail .

If by "option" you mean changing active theme an applying it in IDE, this is the wrong place. Dropdown with theme selection there will not change the theme, it is only a selector for setting background options for each available theme.

Where are you changing theme to Mountain Mist? Welcome page settings are meant to customize Welcome page settings for all themes, not for setting active theme. You can change active theme at User Interface -> Theme Manager page in Options.

LOL I should have known better than doing math first thing on Sunday morning.

I forgot to mention, in original code, merely declaring num as Integer gives 50% increase in the performance.

I don't know about FreePascal, but there are several things that have impact in Delphi compiler. First, being single pass compiler, possible compiler optimizations are more limited than in multiple pass compilers. Next, 64bit compiler in general has less optimizations than original Win32 compiler. I am not going into the why's because I don't have that information and everything would be pure speculation on my side. Also Delphi 64bit compiler is not optimally using all available CPU registers, so there will be more unnecessary memory operations. I know that having a compiler that can do more optimizations is beneficial, because you can focus on the code you write and not on how fast it will run, but whether we like it or not, when speed matters optimizing the algorithm has always been first step. For instance, this would be faster way to achieve same results: var total, num: Int64; begin total := 0; num := 3; while num <= 1000000000 do begin total := total + num; inc(num, 3); end; num := 5; while num <= 1000000000 do begin total := total + num; inc(num, 5); end; end; I know that this is not exactly the answer you are looking for.

People were confused by previous numbering scheme and plenty of people thought that 10.1, 10.2, 10.3 and 10.4 were just updates not major releases. So current numbering scheme for major releases is full number 11 vas major release and 11.1 is update (there were several patches, but they didn't have separate number) and next major release will be 12. Of course, it is possible that there will be other updates for version 11.

Logging problems with Quality Portal are nothing new. I had them for at least a year. I am logging in every day, and at least once a week I run into captcha glitch and I cannot pass it. Clearing cookies usually helps.

Issue needs to be reported only once. Adding duplicate reports does not help in solving issue faster. When there is a duplicate report of any issue those are closed as duplicates to enable tracking status in one point not all over the place. This has nothing to do with statistics, this is basic QA workflow. It would be nice to have official statement, but there is not much anyone here can do about it.

Cloud is just someone else's computer and those fail, too.

That it is not constantly offline for over a week, but that it goes online-offline. Though it is way more offline than online. It is just an observational fact, nothing more.

It is coming online at times, but only for a short periods.

If application worked correctly before the changes, then those code changes will be the cause of the issue, not the TreeView. I suggest going back through your changes history, finding out the last good version of your code. By comparing the code between good and bad version you can more easily pinpoint the real cause.

I am usually all for warnings as they can help you detecting bad code and preventing bad code prevents bugs. But if there is a price to pay, if the warning makes too much noise, then such warning does more harm than good. Crappifying the code and losing the performance, just to catch few places where you turned off your brain before writing the code, is not an option for me. There are other tools that can catch such issues, compiler doesn't have to do everything. Having the same warning for all implies that we wouldn't have the ability to disable var parameter warning without impacting all other places. If var parameter warning would be a separate one, that would be acceptable..

Easier said than done.