Dalija Prasnikar

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.

But, Delphi out parameters have some unpleasantries and many developers choose to use var instead. https://delphisorcery.blogspot.com/2021/04/out-parameters-are-just-bad-var.html

Yes, you were lucky. Uninitialized variable will contain whatever was previously written at that location. If you were lucky enough that value is zero, broken code would work. Yes, there is a compiler difference one is 32bit compiler another is 64bit one. Pointer sizes are different. Memory layout will be different. But, different compiler is besides the point. Working with uninitialized variables is undefined behavior. That means anything can happen even with the same compiler.

TMessage from System.Messaging? System.Messaging is not thread-safe so you cannot use it for anything thread related.

Different languages have different set of features and also differ in implementations of those features. Properties in general are a tool that provides additional level of abstraction around encapsulation and enables future implementation changes while preserving stable public API. Some of the benefits are more visible in some languages than the others. For instance, if you have public field Name and you want to add some code around retrieving that field is easy to do in Delphi. You can rename field and move it to private section and declare public function Name to retrieve it. I Java, you cannot do such thing because calling method must include brackets. This requires refactoring all code that uses such field. If you want to add setter, you will break the code in any language. This is where using properties helps with encapsulation. They hide unnecessary implementation details and give implementing class to ability to change those without breaking user code. You can start with simple field backed property, which from performance aspect is no different than public field and you can add getters and setters as needed without breaking code. Without properties, you can also maintain stable API, but the cost is having getters and setters for everything and paying the price in performance. No matter how small it is, eventually it can add up. Additionally, code with simple assignment is easier to read than setter method. There are some parts of general properties functionality that Delphi does not implement, like different access levels for reading and writing, or some additional ceremony when declaring properties, especially in interfaces. Some of those could be improved to make properties more flexible, but lacking them is poor argument against using properties. In situations where you really need some functionality properties don't provide, you can use other ways to achieve what you need, but not using properties everywhere else because you cannot do something in rare occasions is also not very convincing argument. Arguments around name refactoring are not very convincing either. They compare name refactoring, where there is a bit more renaming in declaration. Now, compare that single place where you need to make additional rename, to refactoring all code in case where you need to replace public fields with accessor methods. When it comes to extra declaration code needed for properties with accessor methods comparing to only having accessor methods, think how much unnecessary getters and setter methods you need to write in cases where you could use field backed property declaration. Overall using properties results with cleaner code and having more functionality than you can have with simple fields or just accessor methods. The little bit of ceremony around the declaration is price I am more than willing to pay, to get all other benefits.

You cannot use property. The only thing you can do is removing property and static getter and renaming virtual getter function to id.

procedure TForm2.Button1Click(Sender: TObject); begin Edit1.Text := inttostr(TChild.id) { <= Calling the Child's property} end; When you use the above call, TChild.id calls static GetMasterID method. Because that method is static it does not have Self parameter passed, which in context of class methods represents class itself. So when you are inside GetMasterID method, compiler no longer knows from which class you have called that method. It only knows the class where the method is implemented, in this case TMaster. And calling GetChildID will be interpreted as calling TMaster.GetChildID. If you remove abstract on TMaster.GetChildID and implement that function as regular virtual method, which returns different integer than TChild.GetChildID you will no longer have abstract exception, but you will get wrong results.

Testing is one things, calling something that serves no purpose is another. If the system is over stressed then pumping messages from UpdateLV will not make it run any faster. If the system is not stressed it will pump messages even without you forcing it, literally as soon as you exit UpdateLV method. If you have too many items on list view and UpdateLV is killing your overal performance, then you should modify that logic and instead of updating the whole list all the time update only item that is modified. Yes, you could see some differences in behavior with Application.ProcessMessages, but none that really matter. Just remove those.