Dalija Prasnikar

VCL implements "garbage collection" for unused device contexts and it periodically releases them. To prevent that you need to call Lock on Canvas, and call Unlock when you no longer need the same device context. But, without seeing your code it is hard to say whether there is more going on.

Another solution that also reduces the binary size is disabling unnecessary Java libraries. By default projects include all kinds of things, like Billing, FireBase, various Google Play services... and if they are not used in the application, they will just be a dead weight.

This is very strange. But the whole issue has been strange from the beginning. AddLog should work both inside or outside task. The only possible explanation would be that AddLog was never called from within the task because some code before it is called triggered exception.

Yes, your code works for me. so the problem must be in some other code you have. Is the AddLog procedure called at all, or just the writing to file does not work? The best thing you can do is to create empty project and test writing to log there.

Saving to log file works fine to me (from the task). The only thing I noticed is that you don't have ErrorData defined within the AddLog procedure. Move it inside, as there is no reason to have broader scope.

Have you tried debugging? Besides the fact that your AddLog code is not exactly thread-safe (if you call it from multiple threads, you can get corrupted log), there is nothing there preventing it to work. And the thread-safety issue would be solved with TThread.Sysnchronize call. So if there is nothing written, your code probably never reaches AddLog call. Make sure that there is no exception raised before that call.

My projects are all rather small, regardless of the platform and the tools I am using. I am personally using Android Studio with Java. Comparing to Delphi, Android Studio is way more resource hungry and slow. Opening a project takes more than a minute, building about 3 (also highly depends on how AS mood at the moment as rebuilding the same project can last up to 10 minutes). Similar Delphi sized project (actually a tad larger) opens up immediately, and builds in under a minute. AS gobbles up over 4 GB of memory while doing that and burns my CPU at 98%. While Delphi uses a little over 600 MB and 8% CPU. Also I had a AS bug report open for years before it was finally fixed, where it would eat up memory on opening second project, and crawl down to a halt and had to be killed through Task Manager. So if I had to switch projects I had to restart the IDE. I am sayin all this so that people wouldn't think that the grass is much greener on the other side and that there are no problems. But the IDE has more features than Delphi and it definitely has some I would want to have. My son is using IntelliJ for Java, and Rider for C# and he is very satisfied with both.

I think it got a bit further... we are somewhere in the Dark Ages...

Only if you have saved the previous steps, too. It is not useful for situations where you have already changed multiple things and then accidentally make a wrong move which you cannot revert.

There is one other feature I like, is ability to change editor font size in pixels. I would like to use Consolas, but size 10 is too small (13 pix) and size 11 is too large (15 pix). I am using 14 pix in other editors. I would post the QP number for that feature request, but it is currently down. But it seems that this would have to wait for new editor because AFAIK the current one can only deal with size in points. One thing they implemented in Delphi 12 is increasing the line height, which is another important feature, when my eyes switch to overly sensitive mode.

I am used to named parameters in Swift (which you have to explicitly write), so once you get used to the fact there there is more information in code, you learn to easily ignore it when you don't need it, but when you do need it is extremely helpful when you are going through code you are not familiar with or your own old code. Yes, you could also hover over the method to see the names and types, but that significantly slows down reading the code. I even find it helpful for the code I know well. I guess my brain likes the extra information being served on a plate.

Inlay parameter hints. It is extremely useful for reading and understanding the code https://www.jetbrains.com/help/idea/inlay-hints.html#change-inlay-hints-appearance Excluding things that Delphi offers but don't work is tough restriction 😉 Well working code completion and refactoring are next.

Anything from JetBrains... I am not saying that Delphi is stuck in the Stone Age... but it is lagging behind in some areas.

DO NOT DELETE THIS FOLDER It contains license information. If there is a reason for removing or editing some license, it should be done through license manager. If it really needs to be deleted, then copy it to some place first, so you can put it back just in case.

It would help if you would provide more information about the exception. The demo works fine for me.

Because conditional jump requires more logic in compiler than simple single jump. Yes, there are other more complicated things in the compiler, that is besides the point. We are talking about goto command which is rarely used and often even considered obsolete. While it has its use cases, extending the goto functionality is really the last thing we need. In that context how complicated feature might be matters. That is why I (erroneously) opened discussion with how many jumps it needs and this could have been a reason why using goto to jump outside try...finally was not implemented.

The jump to finally happens behind that call. If you use Continue, the jump will become more obvious. File a QP report if you think it is important to have it. You can use any code you wish. Like I have already said, I was wrong that there is only single jump involved for the Break and Continue.

You are right, I forgot that there could be code in the loop after the finally, which requires additional jump.

No, it is not the same functionality. Break and Continue will just make single unconditional jump to the finally, while goto would require two jumps, one of them conditional. It is far from being the same.

You cannot use TMonitor in such scenario as you don't always have live instance to call upon. Also there is a simpler code than your example commonly used for double checked locking. However, that pattern assumes that calling the constructor is all that is needed to fully initialize the object. Only if there is additional initialization needed after construction, there is a need for temporary object. So this code would look like: function GetMyObject: TMyObject; begin if FMyObject = nil then begin FLock.Enter; try if FMyObject = nil then FMyObject := TMyObject.Create; finally FLock.Leave; end; end; Result := FMyObject; end; or with additional initialization function GetMyObject: TMyObject; var TempMyObject: TMyObject; begin if FMyObject = nil then begin FLock.Enter; try if FMyObject = nil then begin TempMyObject := TMyObject.Create; // additional initialization for TempMyObject FMyObject := TempMyObject; end; finally FLock.Leave; end; end; Result := FMyObject; end;

No, it is not only you. I cannot log in either. AFAIK, the IT has been notified.

Can you please show the minimal working example of your code that you have problem with. It is very hard to follow explanations of the code. We need to see exact code, to be able to help and propose solution.

If Foo is reference counted type, then GetFoo will require hidden reference created to properly initialize reference counting, regardless of how DoSomethingWithFoo is declared. If it is declared as const that only means there will be no additional reference counting involved (_IntfCopy and _IntfClear) calls. Hidden reference is equivalent of the explicitly declared local variable. It is created when there is a need for holding a reference to something for calling _IntfCopy and _IntfClear methods. If there is already a reference (when passing parameter to some procedure where parameter is not declared as const) then there will be no hidden reference because _IntfCopy and _IntfClear can be called on that reference directly. Same principle applies not only for interface , but also for other reference counted types like strings and dynamic arrays, the only difference is in particular reference counting methods that will be called.

If it requires reference counting, then there will be hidden reference created behind the scenes and the actual generated code will be the same in both cases.

Ahh... that is a slightly different case... but, yes, it can be a nightmarish scenario. I had some of my own libraries with messed extensions and it took me a while to realize what is wrong.