pyscripter

Wrapping third party components is no different to wrapping VCL controls. Consider all the WrapDelphiXYZ units as demos on how to do that. - Please note that with EnhancedRTTI, the only thing that needs wrapping is events other than simple TNotifyEvent. So the wrapping code would be minimal. - There is no special wrapping needed for DataModules (TComponent descendent). Access to the Screen.DataModules property is already wrapped. - Data Access wrapping is provided by the WrapFireDAC unit - Demo 31 has extensive coverage of Forms (creation, subclassing etc.)

After some investigation I have committed changes that eliminate the exceptions during library finalization. The comment above about hiding the form still stands. If the main form is closed with action caFree, all VCL does, is send a Quit message (i.e. does not hide or free the main form). If the application is not terminated (as is the case when running in PyScripter) the form is not closed. You need to hide it using f.Hide(). In PyScripter the python application is truly terminated when you reinitialize the interpreter or close down PyScripter.

Python 2 support was dropped recently. But you can use the last release with Python 2 support. The VCL code is executed in the main thread. ExitThread and ExitProcess are called by python on shutdown. After Run is executed control is passed back to python. In a standalone run python would exit at that point. When run inside an IDE things may be different since the IDE will terminate the python process when appropriate.

You only need to change the following two lines to match your python version: // Adapt to the desired python version - Will only work with this version gEngine.RegVersion := '3.8'; gEngine.DllName := 'python38.dll'; I am happy to evaluate PRs in relation to the termination issue. As I said it does work well when you run the python script standalone (not from a python IDE)

The application terminates fine when run from the command line. You are right that when is run from PyScripter the form does not close. I am not fully sure, but it may have to do with the fact that PyScripter prevents the script from terminating so that the state of the interpreter can be examined after running a script. However you can hide the form by adding f.Hide() as the last statement of the main procedure.

Did you try handling the Form OnClose event or use Release instead of Close?

Please file appropriate bug reports and open PRs, On note regarding WrapDelphi: The WrapDelphiXYZ units were written before the enhanced RTTI was implemented. Nowadays you do not need to wrap enumerations sets and the like. Here is an example from WrapDelphi unit tests: type TFruit = (Apple, Banana, Orange); TFruits = set of TFruit; TTestRttiAccess = class private FFruit: TFruit; FFruits: TFruits; public FruitField :TFruit; FruitsField: TFruits; StringField: string; DoubleField: double; ObjectField: TObject; RecordField: TTestRecord; InterfaceField: ITestInterface; procedure BuyFruits(AFruits: TFruits); property Fruit: TFruit read FFruit write FFruit; property Fruits: TFruits read FFruits write FFruits; end; With the above declarations and if you Wrap a variable say test of type TTestRttiAccess you can write python code such as: test.Fruit = 'Apple' test.Fruits = ['Apple', 'Banana'] So there is no need to create special wrappers of enumerations and sets. The WrapDelphi unit tests are worth studying in some depth.

I would like to use the Delphi-Praxis Third-Party section as a support forum for Python4Delphi. Any idea how a subforum for Python4Delphi can be created?

@DanielCould you please create a subforum in the Third-Party section for Python4Delphi?

No the performance issue was https://quality.embarcadero.com/browse/RSP-23095 also fixed as suggested. https://quality.embarcadero.com/browse/RSP-23093 was a memory leak issue. Please read the reports. In both issues the suggested solution was implemented.

Glad to hear that! So it must be https://quality.embarcadero.com/browse/RSP-23093 that was causing the issue.

function TObjSvr.ObjAddRef: Integer; begin OutputDebugString(PChar(Format('TObjSvr ($%08X) AddRef', [integer(Self)]))); end; function TObjSvr.ObjRelease: Integer; begin OutputDebugString(PChar(Format('TObjSvr ($%08X) Release', [integer(Self)]))); end; Υour are overriding ObjAddRef, ObjRelease, without calling the inherited method. and you expect to see no memory leaks?

The first VCS I used a long-time ago were CVS and FreeVCS (anyone remembers that?). In the days of Google code, I became an SVN fan using TortoiseSVN. When Google Code shut down all projects moved to Github and converted to git. But, I was very reluctant to move to git and carried on using SVN to work with Git repositories. Soon, I realize this change-resisting approach was counter-productive. I then switched to TortoiseGit and never looked back. Having to fork a repository to submit a PR is rather cumbersome (I wish you could do that from a clone), but I do understand the reasons why this is so.

I have added a workaround for https://quality.embarcadero.com/browse/RSP-31170

Just reported two QA issues relevant if you are planning to use/deploy TEdgeBrowser: https://quality.embarcadero.com/browse/RSP-31163 https://quality.embarcadero.com/browse/RSP-31170

This one was fixed in 10.4 https://quality.embarcadero.com/browse/RSP-23093 @NamoRamanaYou should provide a simple test case that reproduces the issue. Otherwise we are all guessing and hand-waving.

TControl.SetParent contains the following code: if not (csLoading in ComponentState) and not (csDesigning in ComponentState) and not (csDestroying in ComponentState) and not (csFreeNotification in ComponentState) then begin if not (csDesigning in Parent.ComponentState) then ScaleForPPI(GetParentCurrentDpi); end; Apart from the fact that I would write the if condition as if [csLoading, csDesigning, csDestroying, csFreeNotification] * ComponentState = [] then does anyone have any idea why controls with csFreeNotification are not scaled? This makes writing per Monitor DPI aware applications much harder.

The workaround for both issues is to follow a pattern such as this: Form.SetParent(Panel); Form.HandleNeeded; Form.ScaleForPPI(Panel.CurrentPPI);

This is another tough one to work around: procedure TCustomForm.ScaleForPPIRect(NewPPI: Integer; NewRect: PRect); var LCurrentPixelsPerInch: Integer; I: Integer; PriorHeight: Integer; begin if not (csDesigning in ComponentState) and ((not HandleAllocated and (Parent <> nil)) or (NewPPI < 30)) then Exit; Parented forms with unallocated handle are not scaled (e.g. page-like controls). It becomes even harder since TCustomForm.SetParent destroys the handle if the form had no parent. This is irrespective of FreeNotifications.

https://community.idera.com/developer-tools/b/blog/posts/august-2019-delphi-android-beta-plans-august-roadmap-update It was planned for mid-2020. But it is late.

@Uwe Raabe Thanks! Good to know I am not the only one bitten by this (should have checked QA), but bad to know it has not been fixed for quite some time now. I placed my vote on the first issue. You can work around the bug by manually calling ScaleForPPI(future parent PPI) before setting the parent but it gets difficult to get right with things like docking. Embarcadero will face this issue when they try to make the IDE per monitor DPI-aware as promised.

Does anybody know why WideStringToUCS4String adds 0 zero as the last character? Surprisingly, Length(WideStringToUCS4String('')) returns 1 and Length(WideStringToUCS4String('abc')) returns 4.

The issue is the in-memory representation of USC4. Should it have the redundant (obviously, no need to make the same argument multiple times ) #0 or not? And I argued that for inter-operability (passing a pointer to external functions expecting null-terminated UCS4) it is better that it always includes it despite the redundancy. And this is what the RTL assumes and does.

You don't have to use USC4 for that and using USC4 would not solve this problem. There are mainly two issues: 1) Surrogates pairs (two widechars correspond to one glyph) UCS4 would help with this one. UTF-16 Encoding: 0xD83D 0xDCBC “💼” 2) Combining characters (more than one Widechars shown as one glyph). But UCS4 would not help with this one. Åström ḱṷṓn Precomposed vrs Decomposed ḱṷṓn (U+1E31 U+1E77 U+1E53 U+006E) ḱṷṓn (U+006B U+0301 U+0075 U+032D U+006F U+0304 U+0301 U+006E) Windows provides CharNext/Prev that deals with both issues, but not perfectly. You have to use Uniscribe or DirectWrite for greater accuracy. In SynEdit there is this function: function SynCharNext(P: PWideChar; out Element : String) : WideChar; overload; Var Start : PWideChar; begin Start := P; Result := Windows.CharNext(P); SetString(Element, Start, Result - Start); end; It is very easy to write an enumerator that works with CharNext.

Why should any Delphi program use UCS4? The main use case is for inter-operability. You would need to pass the result to some external function. Having to manually add the null-terminator, would be inconvenient.