pyscripter

Alexandria with patches.

Win32 and Win64. The problem was that the following was in the project file: <PropertyGroup Condition="'$(Cfg_2)'!=''"> <DCC_Define>DEBUG;$(DCC_Define)</DCC_Define> <Manifest_File>$(BDS)\bin\default_app.manifest</Manifest_File> </PropertyGroup> which was overriding the platform settings. I don't know how this got into the project file. Project Magician was not cleaning it and this was overriding the platform settings. After deleting the Manifest line in the above, things seem to work as expected. One more question. I have a build event defined for all configurations. Delphi keeps one replicating that for every configuration: <PropertyGroup Condition="'$(Config)'=='Debug' And '$(Platform)'=='Win32'"> <PreBuildEvent/> <PreBuildEventIgnoreExitCode>False</PreBuildEventIgnoreExitCode> <PreLinkEvent/> <PreLinkEventIgnoreExitCode>False</PreLinkEventIgnoreExitCode> <PostBuildEvent>copy "$(BDS)\Redist\$(Platform)\WebView2Loader.dll" $(OUTPUTDIR) </PostBuildEvent> <PostBuildEventIgnoreExitCode>False</PostBuildEventIgnoreExitCode> </PropertyGroup> The above is replicated for all configurations. Even when I manually delete the above from the project file manually, Delphi recreates it. Any idea why? Could that be cleaned up?

In Project Magician options "Clear Application Settings" is set on by default. But I still cannot set Manifest options for all configurations. How do I do that? Update: RTDS "All application settings in child configurations are removed and the base settings put in charge again. This effects the Icons, Manifest File, Output Settings and Appearance. Application settings are always platform based and thus the settings in the platform base configuration are the ones to be kept." I need to set them for each platform.

There are a few choices when it comes to native processing and rendering of Unicode text in Windows applications. Namely, GDI, GDI+, UniScribe and DirectWrite. I have been doing some research in the process of updating/fixing the Unicode handling in SynEdit. It appears that the future lies with DirectWrite. Here are some reasons: WPF is based on DirectWrite Recent Microsoft applications, such as the Windows Terminal, use DirectWrite The Windows App SDK (new name of Project Reunion) is using a new cross-platform version of DirectWrite called DWriteCore, which is mostly compatible with DirectWrite. So presumably, switching to DWriteCore, if needed, would be easy. DirectWrite has many advantages including: Can play with GDI well, so you can mix the two. Supports color fonts Handles Unicode such as emojis reasonably well. Supports bi-directional text (e.g. mixing Arabic with English) Provides GPU acceleration. The downside is that it is fairly complex and there is not much Delphi Code that is using DirectWrite. Also the Delphi header translations have bugs and have not been updated for years (see [RSP-36642] CreateGdiCompatibleTextLayout is declared wrongly in Winapi.D2D1 - Embarcadero Technologies for instance). Further to the discussion in Unicode string - how element iterating? - RTL and Delphi Object Pascal - Delphi-PRAXiS [en] (delphipraxis.net), I have created a little demo which showcases rendering complex Unicode text with DirectWrite and also provides a Grapheme enumerator for Delphi strings also based on DirectWrite. Here is a screenshot. The ListBox shows the graphemes of the text. It is custom painted with DirectWrite. The Emoji consists of 7 unicode codepoints. See also fdwr/TextLayoutSampler: Utility to display text via multiple Windows API's simultaneously (D2D, DWrite, GDI, GDI+). (github.com) The source code of the project is attached. DirectWriteTest.zip

A workaround for this python regression has been committed to the repo.

Is this a failure to load the python DLL or an error when executing python scripts? Are you using the latest sources from the Github repo? Also check out the following: FindingPython · pyscripter/python4delphi Wiki (github.com) MaskFPUExceptions · pyscripter/python4delphi Wiki (github.com) If you are using python version 3.11.1 then please try with version 3.11.0 or earlier. There is a change related to the loading of dynamic libraries (dll) in 3.11.1, that I am looking into. See regression with latest Python 3.11.1 and _socket not found · Issue #100171 · python/cpython (github.com)

Sorry. I meant iOS not supported.

I have just noticed that Ctrl+F does not work in my Desktop Delphi 11.2 help files. (Windows 11 22H2). But it works in my laptop, which is also Windows 11 22H2. Strangely Ctrl+F does not work with PyScripter help on either the Desktop or the Laptop. Weird.

Please post questions regarding P4D to the Third Party P4D support forum. What is this InitThread? Using python threads requires deep knowledge of the Python API and the complexities of GIL. If do have to use threads, please study Demo 11 and the related posts in the P4D forum Showing results for 'Py_Begin_Allow_Threads'. - Delphi-PRAXiS [en] (delphipraxis.net)

iOS is supported. For Android look at the Embarcadero fork.

Which Delphi version? Which Windows version? Could you please try using the Delphi way? Add Vcl.HTMLHelpViewer to the dpr uses clause Set Application.HelpFile = to your chm file Use the Application Help commands to invoke help (e.g. Application.HelpShowTableOfContents. Application.HelpContext etc.)

Thanks for responding. No, it is not that. I have tested with a new minimal app, just a form and a button to open the help file, and the issue still exists. I think it used to work with earlier versions of Windows/Delphi.

I dont't think python 11 is supported yet.

In PyScripter we use dxgettext along with https://www.transifex.com/ for translations teams collaboration and github integration. dxgettext offers a great deal of control as to what should get translated and there is an advantage in using industry standard translation formats for which a variety of editing and management tools exist.

Indeed. As I said it is not foolproof. If you use a specific set of python modules, you can see in Delphi's debug mode which DLLs are loaded when your python scripts execute. You can then write code to unload them after unloading python. Failing to unload a DLL does not necessarily mean that there will be an issue next time you load python.

Running python in threads does not increase python code speed due to the GIL. Only one thread executes at any point in time. Torch can do its own mutli-threading so again there is no need to use threads. The main reason for using python threads is to avoid blocking the UI.

Unloading and reloading has always been possible with P4D, but quite tricky and not foolproof. You need to manually unload the dll's loaded by imported modules and if you fail to do that it will fail. PyScripter does that and allows you to change python version without exiting.

Why are you making things complicated? Follow the KISS rule. Using threads in this way requires deep knowledge of the Python API and the complexities of GIL. If do have to use threads, please study Demo 11 and the related posts in this forum Showing results for 'Py_Begin_Allow_Threads'. - Delphi-PRAXiS [en] (delphipraxis.net)

It does, but it is not a good idea and should be avoided. See demo34 for how it can work. This demonstrates also AutoLoad = False

Set AutoLoad to False and call LoadDLL at Runtime (e.g. in your FormCreate).

PythonHome needs to be set even for registered conda distributions See TPythonVersion.AssignTo(PythonEngine: TPersistent); in PythonVersions.pas about this is done. Note also that for conda distributions to work properly, you need to add Format('%s;%0:s\Library\bin;', [Version.InstallPath] to your Windows path if it is not there already.

Is there another sqlite dll in your path?

It is cross-platform. It supports all targets Delphi supports.

Same here. 11.1 was better I think with respect to LSP.

In general, Python scripts run just as fast (or better just as slow) using P4D in Delphi, as they do using python.exe. You need to show what you are doing in that respect.