pyscripter

But so do overwritten methods, virtual methods etc.

This was a python reference counting issue. Fixed in version control. Please try the latest version and confirm the issue is solved.

Are you following the instructions at Installation · pyscripter/python4delphi Wiki (github.com)? Specifically, did you build all packages before installing them?

Clear the output?

This project deserves some attention (greenlets-coroutines, generators, channels and more). It is based on fibers.

You cannot load multiple versions of any dll simultaneously in a single process. If you study Demo 33, you will see that this is not necessarily the case.

Why do you conclude that? If you want to run python code in threads, please study Demo 33 and search for related content in this forum (there is lots). Also google for "Global Interpreter Lock".

In my Delphi apps, I use the dated CHM Html Help format to provide user help. When help is invoked from the Delphi app using the Application help commands, Ctrl+F to search within a help page does not work. However, if open the same chm file outside the Delphi app, Ctrl+F works fine. Any clues as to what causes this issue? Note: The Delphi app is compiled with Alexandria (v11) and I am testing on Windows 11.

Running python in threads is not straightforward. Have a look at TPythonThread, Demo 33, and search this forum for relevant discussions.

Then try the following before loading the engine: - Create a TPythonInputOutput - Set the PythonEngine IO property to the TPythonInputOutput - Set the RedirectIO property to True.

Looks like the python module is trying to write to the console. Do you use TPythonGUIInputOutput linked to the PythonEngine? If not try setting UseWindowsConsole to True.

Did you mask exceptions (MaskFPUExceptions · pyscripter/python4delphi Wiki (github.com)? If yes, have you checked sys.version and sys.path to make sure they are the same as in stand alone python?

You can either install python and PyPDF2 in the target machine or distribute an embedded version of Python with your app. If you follow the second route, have a look at Embarcadero/PythonEnviroments: Components to simplify the deployment for Python environments for Delphi applications using Python4Delphi. (github.com).

Did you use the GetIt version? If not have you read Installation · pyscripter/python4delphi Wiki (github.com)?

I have recently submitted two Vcl related quality issue reports: https://quality.embarcadero.com/browse/RSP-41987 https://quality.embarcadero.com/browse/RSP-41988 The first one relates to a change in TCustomForm.SetParent introduced in Delphi Alexandria. It broke docking behaviour, but there may be other applications affected. One way to work around it is to set the form AutoScroll property to True. Question: Are there any undesired consequences of doing this? The second report relates to the fact that TControlForm.ChangeScale is not used and there is no good available options to achieve what you do when you overwrite ChangeScale in custom controls. Question: Am I missing something? Is there a good way to execute some code whenever the form dpi is changed?

Have you read these: MaskFPUExceptions · pyscripter/python4delphi Wiki (github.com) FindingPython · pyscripter/python4delphi Wiki (github.com) with reference to Anaconda?

This is an old thread, but I have just noticed that Delphi 11 deals with this issue by calling the new LockDrawing/UnlockDrawing wrapper around WM_SETREDRAW in DoBeforeMonitorDpiChanged/DoAfterMonitorDpiChanged. They have also fixed https://quality.embarcadero.com/browse/RSP-30931. It seems to work reasonably well now.

See [RSP-41949] LSP does not work when project includes modified file found in the search path - Embarcadero Technologies for details. Has anyone been bitten by this? Code Insight now works in my PyScripter project. I thought that cyclic unit dependencies may be the cause and spent quite a bit of time reducing them. I guess, that this was time well spent, but it was not the source of the LSP failures.

It turns out that the causes of LSP failure were more complex than I originally thought. In the attached project in TestCI-JclSysUtils LSP does not work. The project is relatively simple. It has three units Unit1.pas (a form with one button) uCommonFunctions.pas (contains three functions) JclSysUtils (an exact copy of the Jcl unit) With Jcl installed it compiles and runs fine. Here is the interesting thing. LSP starts working if: either you remove an unused import of JclPeImage from the uses clauses of uCommonFunctions or you remove the "forked" JclSysUtils from the project. Looks like LSP is a lot more fragile than is should be. I was without IDE support in my a project, since Delphi 11.2 was released and it took substantial effort and a bit of luck to restore it. TestCI-JclSysUtils.zip

@programmerdelphi2k You are right. It works with WinApi.Messages. I have added another project with JclSysUtils instead of WinApi.Messages. The project will compile fine if you have Jcl installed. LSP fails with that project. It also fails if you use System.Variants instead of WinApi.Messages. But in that case the project does not compile. I will try to find out what triggers the failure.

@Brandon Staggs Could you please try the minimal project attached to the QA report. Does it work for you? I think the bug affects units that either use directly the forked units or units that depend on such units.

Development of SynEdit at PyScripter has been moved to and merged with TurboPack SynEdit. The focus of the development is to modernize the code base and enhance the functionality (sometimes at the expense of backward compatibility). In addition to the earlier enhancements and fixes two more features have been recently added: Per-monitor DPI awareness Support for Font Ligatures (new option eoShowLigatures) Fonts like Cascadia Code and Fira Code contain ligatures relevant to programming. See this article for details. Are you using font ligatures? Do you like them? See sample. Thanks to vhanla for contributing the ligature support.

PyScripter, an Open Source, freely available Python IDE written in Delphi, has reached 1 million downloads from Sourceforge. This is in addition to many millions of downloads from its earlier home at the now defunct Google Code and an unknown number of downloads from other distribution channels. Historic note: The initial motivation was to build a good scripting solution for Delphi applications. About 20 years ago Microsoft was still promoting ActiveX scripting and Windows Script Engines (such as vbScript and jScript) as the way of building scripting solutions for Windows applications (one of many Microsoft technologies that was all but abandoned). At that time Python was relatively unknown, but it so happened that it was available as a Windows Script Engine and I looked into it. I loved the clean syntax, the expressiveness and conciseness of the language. Other things I liked were duck typing, batteries included, strong object orientation (everything is an object) etc.. The first iteration was an IDE (editor/debugger) for ActiveX Script Engines. But there were many bugs and limitations of Active Scripting both on the Microsoft/Windows side and the Python side. I then came across Python4Delphi which at the time was maintained by a Canadian developer Morgan Martinet. I started contributing to that project and later become its main maintainer, when Morgan's interested shifted to other things. I also developed a simple Python IDE which was named PyScripter and was originally distributed alongside Python4Delphi. There was very few Python IDEs available at the time and somehow the project became known in the Python community and instantly popular. For me, developing PyScripter was just a hobby, but I received a lot of encouragement and kept on improving it. I was also making some income from donations and Google AdSense. Both PyScripter and Python4Delphi were later moved to Google Code. Python popularity was steadily increasing and at the peak of PyScripter's popularity around 2010, there were hundreds of thousands of downloads the days following each new release. More recently as we all know Python became one of the most popular programming languages, but at the same time there was strong competition to PyScripter from freely available commercial grade IDE's such as Jetbrains PyCharm and Microsoft's Visual Studio and Visual Studio Code. PyScripter was almost abandoned when Google Code closed down due to my frustration, but after a couple of years of inactivity the project was moved to Github and development resumed. Downloads are available through Sourceforge, since 2016. Through the years PyScripter has kept a large and loyal group of followers. I get many comments along the lines "I have tried VSCode, I have tried PyCharm, but I keep going back to PyScripter". PyScripter is also quite widely used in many Universities for introducing Python to students. And almost 20 years after its first release, PyScripter is still going strong...

PyScripter has reached 1.5 million downloads. This is just from Sourceforge and does not include downloads from Embarcadero, many other download sites and forks such as GuiPy. What is quite satisfying is that there is no country in the world without downloads. Greenland for instance, a vast country with a population of only 56000, has 7 downloads.

When I debug my application, just before exiting, I see some strange messages in the Events log, such as: Debug Output: onecore\com\combase\winrt\error\restrictederror.cpp(945)\combase.dll!00007FFD636832D1: (caller: 00007FFD6358BCC5) ReturnHr(4) tid(b80) 80070490 Element not found. Process PyScripter.exe (14872) All messages are related to winrt, however I am not explicitly using winrt. Any clues? Should I worry?