pyscripter

This is indeed weird. In fact, just turning the Visible property of the ListView to False prevents the error. Some further observations: I confirm that WMDestroy is not received by the treeview The bug is definitely related to Vcl.Styles. If you change the style to a Vcl.Style and then back to Windows, the error does not occur You can prevent the error by calling Treeview.Items.Clear in the FormCloseQuery event handler. Strangely calling RecreateWnd in the same handler also prevents the error.

You need to add: {$I Definition.inc} to the Demo 31 Unit1.pas It was accidentally deleted in a recent commit. This is now fixed.

@David MillingtonMaybe you could enlighten us as to the nature of the changes that made the Delphi IDE behave better with RD. Are there any lessons to be learnt by Delphi developers?

Please update to the most recent version. Demo7 is fixed. I can run Demo31 without any issues.

@Darian Millerhas published a very nice article about the state of TThreadedQueue and TMonitor in Delphi. He has also published at Github a stress test that shows how TThreadQueue still fails under stress. I have played with his stress test and concluded that the problem is almost certainly in TMonitor. TMonitor implements a lock-free stack to recycle events created with the CreateEvent function. The relevant code in SysUtils is var EventCache: PEventItemHolder; EventItemHolders: PEventItemHolder; procedure Push(var Stack: PEventItemHolder; EventItem: PEventItemHolder); var LStack: PEventItemHolder; begin repeat LStack := Stack; EventItem.Next := LStack; until AtomicCmpExchange(Pointer(Stack), EventItem, LStack) = LStack; end; function Pop(var Stack: PEventItemHolder): PEventItemHolder; begin repeat Result := Stack; if Result = nil then Exit; until AtomicCmpExchange(Pointer(Stack), Result.Next, Result) = Result; end; This lock-free stack is used by NewWaitObj and FreeWaitObj which are part of the Monitor support protocol and used by TMonitor. This works reasonably well, but under stress it fails. The reason it fails is known as the ABA problem and is discussed in a similar context by a series of excellent blog posts by @Primož Gabrijelčič: blog post 1, blog post 2, blog post 3. His OmniThreadLibrary contains the following routine that he uses to deal with this problem. /either 8-byte or 16-byte CAS, depending on the platform; destination must be propely aligned (8- or 16-byte) function CAS(const oldData: pointer; oldReference: NativeInt; newData: pointer; newReference: NativeInt; var destination): boolean; asm {$IFNDEF CPUX64} push edi push ebx mov ebx, newData mov ecx, newReference mov edi, destination lock cmpxchg8b qword ptr [edi] pop ebx pop edi {$ELSE CPUX64} .noframe push rbx //rsp := rsp - 8 ! mov rax, oldData mov rbx, newData mov rcx, newReference mov r8, [destination + 8] //+8 with respect to .noframe lock cmpxchg16b [r8] pop rbx {$ENDIF CPUX64} setz al end; { CAS } I have tried to use this function to provide a solution for TMonitor similar to the one in OmniThreadLibrary. (see attached iaStressTest.TThreadedQueue.PopItem that can be used with the original stress test). Whilst still not perfect it helps a lot in 32 bits with say up to 100 threads. However it crashes in 64bits and I do not know why. I am posting this here in case anyone with better knowledge than mine of assembler and thread programming can help with the challenge of fixing TMonitor. It would be nice to try and get a fix included in 10.4. And even if it is not included, it can be easily used as a patch in the same way as in the attached code. iaStressTest.TThreadedQueue.PopItem.pas

This makes sense. "Finish incomplete properties" can be very annoying when combined with "Auto invoke" so it is disabled.

Could it be that you have unchecked the "Finish incomplete properties"? Works here as expected.

No need for any of that, if you are not building applications with run-time packages and most likely you are not. Just change the platform of your project to Win64 and build it.

Fixed in version control. See https://github.com/pyscripter/python4delphi/issues/292 Now SystemExit results in a EPySystemExit exception which can be handled in Delphi code. Process termination is prevented.

P4D does something similar with custom variants and the Varpyth unit.

Which flag do you pass to PyRun_StringFlags?

Any reason for not using P4D?

All of these suggestions can be implemented without modifying your python code. For example you can just add the suggested code to the PythonEngine.InitScript.

@vmishkaYou are using Delphi 10.4 (which is the reason for the problems you are facing). You need to upgrade to 10.4.1 or even better to the just released10.4.2. This is a new installation. You need to download the installer from Registered Products Portal (embarcadero.com)

exit() raises the SystemExit exception, which unlike other exceptions, results in process termination before control gets back to Delphi. To prevent process termination you can do one of the following: wrap the python code in a try: except SystemExit: as suggested by @fjames above "overwrite" the exit method by for example running the following code after the python engine is initialized: def _exit(): print("exit prevented") __builtins__.exit = _exit import sys sys.exit = _exit del(_exit) overwrite the SystemExit exception!

The design time packages are 32-bit so you need to add the paths to the 32-bit target. The group project contains runtime and designtime packages. You first need to compile/build the runtime packages for target 32-bits. Optionally and only if you want to build 64-bit applications with runtime package, build 64-bit runtime packages: - Python270.bpl - PythonVcl270.bpl - PythonFmx270.bpl Then install the Design time packages (these are always 32-bits) - dclPython270.bpl - dclPythonVcl270.bpl - dclPythonFmx270.bpl

I was bitten by this a few times in previous upgrades. This time I knew better...

I think a (the) highlight of this release is fixing [RSP-27375] Compiler generates disadvantageous code for try/finally - Embarcadero Technologies. Thanks to @Mahdi Safsafifor coming up with a great suggestion and @Stefan Glienkefor creating the issue and pushing hard for its resolution.

SVGIconImageList/Demo at master · EtheaDev/SVGIconImageList (github.com) is not a bad starting point for debugging. The treeview has no interaction with the rest of the program.

In the SvgIconImageList demo case, the application was compiled with the Windows default style and the error occurs when you change the style at runtime. I think that may be significant because it causes the controls to be recreated.

Did you see my answer in Demo34 + NumPy · Issue #287 · pyscripter/python4delphi (github.com)? Did you try what I suggested there?

The bug is not related to frames.

@Carlo Barazzetta SVGIconImageList/Demo at master · EtheaDev/SVGIconImageList (github.com) suffers from the same problem.

I am not sure many know that since the Windows Creators update, svg parsing and painting is natively supported and is part of Direct2D. I wanted to test this Windows feature, however, the first obstacle was that the Direct2d headers that come with Delphi are very very old. There are two open tickets in https://quality.embarcadero.com/. Direct2D 1.1 support missing (open since XE7!) Direct2D 1.2 and 1.3 support missing You may want to vote for them, since lack of good Direct2D support (includes DirectWrite) it is a bit of a shame. I then looked at other Direct2D translations and found two that are regularly updated. MfPack DelphiDX12 They both had some issues but that was a good start. It turned out that parsing and painting svg files to Canvas is quite straightforward. Once you establish a renderer (Vcl.Direct2d does this, but it is easy to do it from scratch) you can do everything with two lines of code. fDeviceContext5.CreateSvgDocument(fStream, D2D1SizeF(ClientWidth, ClientHeight), fsvgDocument); fDeviceContext5.DrawSvgDocument(fsvgDocument); You can check whether Svg is supported by: if Supports( rt, ID2D1DeviceContext5, fDeviceContext5) then And it is easy to do things like scaling, opacity, rotation, recoloring etc. The quality and speed appear to be quite good, but there are some limitations, the most important of which I think is the lack of support for the text element. I am attaching the source code of my test project (no dependencies) in case anyone wants to play with it. The Svg scales automatically as you resize the form. Svg.zip

P4D supports named parameters as follows: requests.get('http://192.168.1.200/gci-bin/users', auth:=requests.HTTPDigestAuth('admin','admin') Please note the := notation.