JonRobertson

I've never heard of the Delphi IDE "using" an external editor. The integration between the editor and the rest of the IDE (designer, object inspector, tool palette, etc) would likely need a heavy refactor or rewrite. But as @Lars Fosdal mentioned, you can edit Pascal source in any text editor. The project below is a Delphi plug-in that adds a command to the Tools menu to open the current unit in Visual Code. With a little configuration, you could switch between Delphi and Visual Code at will, taking advantage of features in Visual Code such as Copilot. EditInVsCodeDelphiPlugin

The editor right margin. It is configurable: Tools->Options->User Interface->Editor->Display, in "Margin in gutter" section, "Right margin"

Search for JumpList.TJumpList. Here are a few links to get you started. https://docwiki.embarcadero.com/RADStudio/Athens/en/VCL_Taskbars https://docwiki.embarcadero.com/Libraries/Athens/en/Vcl.JumpList.TCustomJumpList.AddTask https://blog.marcocantu.com/blog/2014-september-vcl-xe7-taskbar-jumplist.html https://perevoznyk.wordpress.com/2011/05/25/adding-windows-7-jump-list-to-a-delphi-2010-application/

A project that I inherited has warning "W1047 Unsafe code" enabled. I normally do not enable that warning. There is a scenario that I don't understand, even after some online searches. [dcc32 Warning] W1047 Unsafe code 'String index to var param' From a couple posts that I read, it seems this specific unsafe warning is related to multiple platform support and zero based strings. It occurs in this (totally useless) code segment: function Test(const aStr: String): String; begin SetLength(Result, Length(aStr)); var Count := 0; for var i := 1 to Length(aStr) do begin Inc(Count); Result[Count] := aStr[i]; end; end; on Result[Count] := aStr; The wording of the warning confuses me. There is an index to a string, but not what I consider a 'string index'. Does the [] operator for String receive the index as a var param?

Yes you do, as long as you have the source code. You have complete control over when a DM is created.

I suggest creating an Issue here. And there is no reason for an option to be added. The plug-in should determine the correct paths and Delphi version without needing you to configure it.

Done. Issue 207

Thanks for the extra info. Downloaded and renamed. The first unit that I tried to analyze gave this error: DelphiLint encountered a problem during analysis. An error was raised (java.lang.OutOfMemoryError: Java heap space ). That unit has 464 lines of code. The entire project has 12,533 lines of code, not counting Delphi RTL, VCL, and third-party components. So this isn't a large project by any means. This laptop has 32GB of physical memory and 13.5 GB was available at the time of the analysis.

Your original declaration declared a pointer, but never assigned it to anything. Since it is a local variable on the stack, it contained a garbage/random value rather than a pointer to actual data. Darian's suggestion changed your declaration to an instance of data. Using @repoPP then passed the memory address (pointer) of the data to the DLL. See The @ Operator

I am curious what the "standalone" version would download from GitHub. Following the link to install SonarDelphi, you need to install SonarQube, then SonarScanner, then install the SonarDelphi plug-in in SonarQube. I installed SonarQube and configured a database via the install instructions. But the SonarQube service refuses to start.

I installed it but I was not able to use it. The first issue is that the BPL is not signed and our corporate policy would not allow Delphi to load the BPL. I worked around the issue by signing the BPL with our code signing certificate. The next issue is that DelphiLint is unable to download SonarDelphi from GitHub. A better error message would be appreciated. The dialog simply says to check my internet connection, which is definitely working at the moment. I am about to download SonarDelphi manually. Hopefully the documentation will have instructions on configuring DelphiLint so it "knows" that SonarDelphi is installed.

That is why I would rename the unit. When the project fails to compile, the error should occur in the unit that is "using" the unwanted unit. Note that it often requires a Build rather than just a Compile to locate the unit containing the reference.

Apparently is possibly accurate. Supposedly is more accurate, at least that was the case six months ago. My rant on DerScanner

And has not been possible since Delphi 1.

Yes, unless you have the C++ source and wanted to create a C++ DLL that could be used from Delphi using a COM interface. http://rvelthuis.de/articles/articles-cppobjs.html

Thanks for letting me know. I do not have much experience with the various DPI issues.

How was it possible with Delphi 1?

Not sharing components, or sharing a single instance of a component. If a frame contains an ImageList and is used on multiple forms, each form creates a separate instance of the frame and all components on the frame. So you have multiple copies of the same ImageList, but those forms are not "sharing" the ImageList. I use a TDataModule for resources and components, such as TImageCollection and TVirtualImageList, that are used by multiple forms.

I don't agree with this. frmView := TfrmView.Create(Self); frmView.Parent := tsView; This makes the tabsheet the parent of the form. So now all controls on the form have the tabsheet as a grandparent, if you will. But the parent of each control on the subform is not changed to the tabsheet.

My laptop's "recommended" scaling is 125%. At the office, I have two external monitors, each has recommended scaling of 150%. I started this position eight months ago. The first project that I worked on uses a "tabbed interface", similar to web browsers, where each form is created and parented to a TTabSheet. Nothing more than setting frmSomeForm.Parent := tsSomeForm. Every form, except a few "dialog box" forms, are embedded in the app's main form. Two of the forms in that application also contain a TFrame, which is on the form at design-time rather than created and attached at run-time. I have not seen any DPI related issues since switching to DPI Unaware mode when launching BDS.

I would agree that it is easier than using C++, among others. But Delphi is also just as capable of generating executables that overwrite memory or have vulnerabilities, due to poor or improper memory handling. In that sense, I don't think Delphi has better memory safety than C++. And certainly capable of being used to intentionally expose memory related vulnerabilities.

The one difference that I encounter is that a "SubForm" is not linked to anything at design-time. If you have placed a TFrame anywhere in the project, the frame is now linked and "in use" by the designer. I often encounter "has open descendents [sic] or linked modules. Cannot close." dialogs when trying to modify a frame, TDataModule descendant, or a base form (when using form inheritance). This often happens when I try to switch between form designer and DFM text editing. I can close every unit that the editor/designer has open, re-open the "linked" unit, and still can't switch to text DFM. At that point, I could just edit the DFM in my favorite text editor, except Delphi will not reload the DFM once my edits are finished. So I typically restart the IDE. I still use D7 occasionally. While this does happen in D7, and I remember it in D6, there seem to be more scenarios where D11 refuses to switch and D7 doesn't.

Although I've been programming for 42 years, I know so little compared to how much there is to know. So thanks for the link. My preference is to handle/control the lifetime of memory allocations based on the purpose and usage, rather than leaving it to algorithms that attempt to figure that out. The code below is a hand-slap, don't ever do that. It was also the first thought I had to show that the memory manager does not "know" anything, unless it is told. Algorithms may be written to read my mind. But I digress... function BadAlloc(Size: NativeInt): String; begin var pStr: PChar; GetMem(pStr, Size); StrPCopy(pStr, 'bad code'); Result := IntToStr(Integer(pStr)); end; procedure BusyProc; begin var myBad := BadAlloc(20); // lots of other busy code... ShowMessage(PChar(StrToInt(myBad))); end; My expectation is that tracing garbage collection could release the 20 byte block immediately after BadAlloc returns, or any other time before the ShowMessage is executed.

The memory manager would have to "know" when the memory was no longer needed, otherwise it would release allocated memory too soon. Unless I don't understand the question, it sounds like Automatic Reference Counting, which was already attempted. And it was later removed for a few reasons.

I do, and I suspect many others do as well "Promoting tools to help in this area" sounds good. But "Sounds good" is marketing rubbish.