Lajos Juhász

In my opinion this is the wrong place to report the error. Delphi compiles the code correctly, your environment is giving the wrong result eg. it's not a compiler bug.

You should try to debug the code. On an Intel Windows laptop I get the correct result '3'.

It should be enough to use IdOpenSSLSetLibPath.

I refuse to use RCS at the moment

TNT is compatible with the new VCL components. To replace them you can simply use the refind utility - https://docwiki.embarcadero.com/RADStudio/Alexandria/en/ReFind.exe,_the_Search_and_Replace_Utility_Using_Perl_RegEx_Expressions. The rules are simply for example: #unuse TntExtCtrls #unuse tntButtons TTntEdit -> TEdit TTntStringGrid -> TStringGrid

In order to do that you have to move your calculation into a background thread. Otherwise your calculation will block the main thread.

For me there was only two cases of false positive. The last time it was this year MS Defender flagged application to be infected. MS solved it within 2-3 days.

Delphi version this requires Delphi 10.3 or newer version (https://docwiki.embarcadero.com/RADStudio/Sydney/en/Inline_Variable_Declaration)

Embarcadero made a form from pyscripter (Embarcadero/python4delphiPublic forked from pyscripter/python4delphi) making the pyscripter to be the "main" repository. In theory all changes makde by Embarcadero should sooner or later be added to the PyScripter repository. According to the webinars I watched they work together to improove the library.

No that's the limitation of the Delphi. It doesn't support exceptions during initialization of the application. The same problem has Skia if the dll is missing (of course in case of skia there is an easy fix replace the exception with showmessage).

You should open a bug ticket at Embarcadero Quality portal - https://quality.embarcadero.com/

I cannot reproduce, you must use some memory hungry components.

dpk of course.

Great work, you should also consider to support packages (dpr files).

You can only hope. I watched the C++ webinar to get an idea what we can expect from D12. The C++ part was far from finished.

It's not the case using Delphi 11.2. Tried to open some forms and the used GDI handles (according to the task manager) keeps growing and doesn't goes back.

In that case windows will run out of GDI handles and give error. A 64 bit version of the IDE would have the same problem.

You should try again, I can access it: Product Registration This page is used to receive product activation information via email. If you have reached this page in an attempt to download software, please go here. Download.

That's easy. The only reason is that they can say that finally managed to copy it from other languages. Lately that's the only driving force behind the R&D.

https://docwiki.embarcadero.com/Libraries/Sydney/en/System.SysUtils.StrToCurr Thousand separators and currency symbols are not allowed in the string. If the string doesn't contain a valid value, StrToCurr raises an EConvertError exception.

I would really like to see a list of problems that a 64 bit IDE could solve.

In the new Delphi roadmap there is a research area to replace the IDE code editor maybe that will bring us closer to 64 bit IDE. In my opinion a 64 bit IDE would not solve the problems. I am from time to time working on a larger code base without a problem. A badly written pacakge can of course destroy the IDE.

I bet the beta testers cannot answer this question without violating the NDA. Earlier it was not allowed even to write about a fact that somebody is a beta tester.

In my opinion it would be better to use: blub:= "line1 line2, indented line3 ;

Could be also objects with owners that are left in the memory. Those objects wouls use memory and be freed before the memory leak report is generated.