Lajos Juhász

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.

You can try https://github.com/Spelt/ZXing.Delphi. I did only a test for VCL and QR codes.

change your regional settings in the IDE. Set your keyboard to for example ENG US.

You cannot make the form in the IDE larger than the resolution of your screen you're working on. This is an insane limitation of the new IDE (can you bite if you have a 4k office monitor and have to work later on a laptop).

You should define your view in Tools - Options. You can find it if you navigate to User Interface - Form Designer - Device Manager or just write Device manager into the search edit box at the top. https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Adding_a_Device_Preset

My only experience with this kind of debugging is that it's going to result a request time out.

Hint: Powered by Invision Community.

I cannot fully understand the question either. My bet is that the TDBgrid for blob fields instead of the value displays (Memo). In order to correct that a solution is to use the OnGetText event of the TMemoField/TWideMemoField:

For me it made unstable. There was no chance to do compile all for a large project group. The solution was to add scopes to unit names and improve code structure and reduce circular references.