pyscripter

SynEdit now has annotated Scrollbars. In this screenshot you can see in the scrollbar: the position of the multiple carets (full blueish line) lines with errors (full red line) the position of the bookmarks (mini bluish marks on the left) line modification info (on the right side) alpha-blended slider This feature is on the multicaret branch. Zoom In/Out/Reset functionality has also been implemented. You can still vote on this poll to influence future development. See the technical details. See also SynEdit now supports mulit-caret, multi-selection editing - I made this - Delphi-PRAXiS [en].

A new powerful highlighter called Omni (for omnipotent) has been added to SynEdit. Importantly, this highlighter allows the saving/loading of highlighter settings to/from ini files. The project now includes 189 new ini-based highlighters in addition to the 75 ones that were already included. Sample using the PowerShell ini-based highlighter. Notice that code-folding is automatically supported. Structure highlighting is also supported: A component editor has also been added that can be used at both design and run-time. See this discussion for details. This is based on a significant code contribution by Jan Fiala, the author of PSPad. Kudos to Jan!

Talking about capitalization, the Delphi Style Guide: is quite clear about: using "Pascal casing" (e.g. MyData) across the board (variables, parameters etc..) fields starting with a capital F. avoiding prefixes such as lData for local variables or aFileName for parameters. The Delphi RTL mostly complies with the above recommendations, but much of the Delphi code around does not. There is also a lot of variation regarding the use of prefixes in control names inside Forms. Spring4D in particular uses camelCasing for parameters and local variables, small f for fields and uses Pascal casing for function/procedure names and properties. @Stefan Glienke Is this just a matter of taste? I can see some advantages in the following convention (a hybrid of the DSG and the spring4d conventions): Properties/function/procedure names use Pascal casing - Inside the class use the field name instead of the corresponding property name. Function/procedure parameters use camelCasing Fields start with F Local variables follow Pascal casing Global variables (just avoid using). In this way you could immediately tell if any variable is a parameter, a local variable or a field without littering the code with ugly prefixes and the like (except for the now established F for fields). And if you follow the rule about properties and avoid with statements, then you would almost always refer to properties using the dot notation. I am not actually using this currently, trying to stick to the Delphi Style Guide. Any thoughts? What is you preferred convention and why? @Joshua Gardner Does the "opinionated" pasfmt take a view on capitalization?

As well as python's black.

And incidentally, for whoever has not tried it, Delphilint from the same group, really rocks.

There is also TryGetValue<T>.

The IDE docking is based on TDockTabSet, which was introduced in Delphi 2005. It has received some attention later including Vcl styling. The only demo I could find is an old one by Jeremy North, but the source code is not available. Jeremy also seemed to have expanded this component in his QualityCentral client (look at the images at the end of the article), the source code of which is also not available. It is not the sleekest implementation, but apparently it works OK in the IDE. Agree in general, but it depends on the application. All the IDEs I know of, including Visual Studio, use docking extensively. Same is true for VS Code for example (but no floating forms though). In PyScripter I use a heavily modified version of JvDocking (part of the JVCL library), but I am still looking for a better open source library. I may have to create one.

I have created a new Delphi application called ChatLLM for chatting with Large Language Models (LLMs). Its primary purpose is to act as a coding assistant. Features: Supports both cloud based LLM models (ChatGPT) and local models using Ollama. Supports both the legacy completions and the chat/completions endpoints. The chat is organized around multiple topics. Can save and restore the chat history and settings. Streamlined user interface. Syntax highlighting of code (python and pascal). High-DPI awareness. The application uses standard HTTP client and JSON components from the Delphi RTL and can be easily integrated in other Delphi applications. You do not need an API key to use Ollama models and usage is free. It provides access to a large number of LLM models such as codegemma from Google and codelllama from Meta. The downside is that it may take a long time to get answers, depending on the question, the size of the model and the power of your CPU and GPU. Chat topics The chat is organized around topics. You can create new topics and move back and forth between the topics using the next/previous buttons on the toolbar. When you save the chat all topics are soved and then restored when you next start the application. Questions within a topic are asked in the context of the previous questions and answers of that topic. Screenshots: Settings using gpt-3.5-turbo, which is cheaper and faster than gpt-4: UI: Further prompting: The code is not actually correct (Serialize returns a string) but it is close. If you want to test ChatLLM you can download the executable.

A new version 1.2.0 of ChatLLM has been released: New Features: Much improved rendering of responses on a par with the Web Chat interfaces of the LLM providers. Syntax highlighting of code (300 languages are now supported thanks to Prism). Support for DeepSeek models Support for reasoning models such as OpenAI's o1-mini and DeeepSeek's deepseek-reasoner. Exposed the temperature LLM parameter. Screenshots: Settings: User interface: Reasoning with deepseek-reasoner: And by the way DeepSeek is so much better than Gemini on Delphi coding.

Looks like an installation problem. Solving the AttributeError: Module 'numpy' has no attribute '__version__' | Saturn Cloud Blog I would start afresh: Uninstall existing python Grab the most recent python from www.python.org Use pip to install any modules you need Then test Open the python CLI >>> import numpy etc. And finally find a good python tutorial to get started, using of course PyScripter.

No idea. If you start a new project, import System.Threading, and use TParallel does it compile?

For years there have been rants about flicker in Vcl applications. So when I tried to fast resize a form with an EdgeBrowser and saw the browser scrollbar jumping right and left, I assumed that it is Delphi's problem. Then I tried the same with Edge and the result was the same. Massive flicker when the scrollbar is visible! Bravo Microsoft! In fact Edge flickers even without scrollbars, whilst Delphi's EdgeBrowser doesn't. By the way does anyone know how to Vcl style the EdgeBrowser scrollbar?

In case anyone has a use for it, here is how you can set the browser color scheme: procedure TForm2.SetColorScheme(Dark: Boolean); var Profile: ICoreWebView2Profile; Scheme: COREWEBVIEW2_PREFERRED_COLOR_SCHEME; begin if Dark then Scheme := COREWEBVIEW2_PREFERRED_COLOR_SCHEME_DARK else Scheme := COREWEBVIEW2_PREFERRED_COLOR_SCHEME_LIGHT; (EdgeBrowser.DefaultInterface as ICoreWebView2_13).Get_Profile(Profile); Profile.Set_PreferredColorScheme(Scheme); end; function IsStyleDark: Boolean; var LStyle: TCustomStyleServices; LColor: TColor; begin Result := False; LStyle := TStyleManager.ActiveStyle; if Assigned(LStyle) then begin LColor := LStyle.GetSystemColor(clWindow); // Check if the background color is dark Result := (LColor and $FFFFFF) < $808080; end; end; Form2.SetColorScheme(IsStyleDark); Form2.EdgeBrowser.NavigateToString(Html);

Just go to www.python.org, download the most recent version and install it. It includes pip.

Use VitrualTreeView. See the demos.

@Erik@Grijjy's neslib/Chet: C Header Translator for Delphi may be worth giving it a try.

Out of curiosity, I tried the CrowdStrike analyzer on the PyScripter setup program (signed). Whilst Falcon and MetaDefender gave a clean record, their Falcon Sandbox report gave a threat score 100/100! The report included the following: This report has 268 indicators that were mapped to 106 attack techniques and 11 tactics - Calls an API typically used to query local/system time as file time - Reads configuration files (.ini files) - Marks file for deletion - Contains ability to load/free library (API string) - Contains ability to modify registry key/value (API string) - Contains ability to set file time (API string) etc. Micorsoft's "MicrosoftEdgeWebview2Setup.exe" fails miserably as well. I am not sure any real-world compiled program would pass all these tests. I don't think there is much to worry about here.

The code of TReader.ReadCollection is as follows: procedure TReader.ReadCollection(const Collection: TCollection); var Item: TPersistent; begin Collection.BeginUpdate; try if not EndOfList then Collection.Clear; while not EndOfList do begin if NextValue in [vaInt8, vaInt16, vaInt32] then ReadInteger; Item := Collection.Add; ReadListBegin; while not EndOfList do ReadProperty(Item); ReadListEnd; end; ReadListEnd; finally Collection.EndUpdate; end; end; It has been like this forever. My question is about the statement: if not EndOfList then Collection.Clear; It means that if you read an empty collection, the collection you are reading is not cleared or otherwise changed. The practical implication of this is that if you have a component that initializes a collection property with some items, there is no way to really clear it from the collection property inspector. Next time the form is loaded, either at run time or at design time, the collection will revert to the initialized state. Can you think of any reason TReader.ReadCollection does this? I think that if you read an empty collection, the collection property you are loading should be cleared. Should I report this as an issue? Also is there any workaround? I want a collection property to have a default state with some items created by the component constructor, but the users to be able to clear it at design time.

Against my better judgement I have submitted an issue report.

pyscripter/python4delphi · Discussions · GitHub pyscripter/SynEdit · Discussions · GitHub

Use the JAM Software one, The reasons: It is the official Virtual Treeview repo. @joachimd took over the project from the component creator Mike Lischke and he is doing a fantastic job. It is very actively maintained. Bug reports are dealt with and fixed very promptly. The GetIt version is based on the Turbopack repo. This repo was created from an older version of the JAM Software one. Surprisingly, it was not forked, so it is hard to compare the two or merge changes from one to the other. If you look at the Commit history it was created in 2014 and since then there have been around 130 commits, mostly creating packages for new versions of Delphi. In the JAM Software repo there have been as many commits in the last six months. Even if you submit a bug report to the Turbopack repo and it gets fixed (don't bet on it), it will take months before these fixes find their way into GetIt. No.

It turns out that the workaround for the second issue is quite simple: procedure TCustomSynEdit.ReadState(Reader: TReader); // If the component is inherited from another form, ReadState will be called // more than once. We only clear the collections if it is the first call // i.e. when reading the base form. begin if not FStateRead then begin FScrollbarAnnotations.Clear; FStateRead := True; end; inherited ReadState(Reader); end; Thanks to @Uwe Raabe for giving me the idea.

@Uwe Raabe@Anders MelanderThank you for your feedback. Fully agree. The chances of Embarcadero changing this old code are close, very close, to zero. However let me elaborate on the problems with the current situation. There are two issues: A) Form Inheritance Consider the attached project, There are two forms, one inheriting from the other. The first contains a TCategoryButtons with two categories (Showing just the relevant part) object Form1: TForm1 object CategoryButtons: TCategoryButtons Categories = < item Caption = 'A' Color = 16771839 Collapsed = False Items = <> end item Caption = 'B' Color = 16771818 Collapsed = False Items = <> end> end end If the inherited form does not change the Categories collection then the dfm of the second form does not have any reference to the Categories collection. inherited Form2: TForm2 inherited CategoryButtons: TCategoryButtons Width = 505 end end If you now remove the two categories in Form2, the form is correctly saved as: inherited Form2: TForm2 inherited CategoryButtons: TCategoryButtons Width = 505 Categories = <> end end However, if you run the application though, Form2 still shows the two categories. Also if you view the form as text and then back as form, the Categories revert to the inherited value. The same happens if you close and reopen the form. This is counter intuitive and problematic. I do not see how clearing the selection on reading would result in any undesired behavior. It would work correctly whether the collection is changed or not, Instead, it would solve the above issue. B) Cannot clear a collection created with items at design time Whilst you both focused on inheritance, for me the most important issue is unrelated to form inheritance. If a custom component contains a Collection property that is initialized non-empty at component creation, there is no way to clear it at design time. As an example, Synedit, has a collection property ScrollbarAnnotations. At construction this is initialized with some default annotations. The user may want to remove all annotations, but this cannot be achieved at design time. If you clear all annotations, the form reverts back to the initial state, when you run the project, or just close and open again the form. I cannot think of any backward compatibility issues that result from clearing the collection on reading empty collections. Can you? FormInheritance.zip

Could you please explain why not clearing the collection plays better with form inheritance? I would think the opposite. Say you inherit from a form with a component that has a collection property with some items. As it stands, there is no way for the inherited form to clear the inherited collection.

The Forum selection issue is also fixed. Thanks!