JonRobertson

Often called managed types in Delphi code, because the compiler manages the lifetime of the heap memory used by those types.

I suspect that depends on the software scanning for virus and malware. My suspicion is that scanners don't care whether applications are signed, because there is nothing that prevents me from applying a security certificate to malicious code. Especially if the certificate cannot be traced back to me.

Are your computers connected to the Internet? Any application can be hijacked by an intrusion from the outside, even applications developed internally.

If your customers use an Endpoint Protection and Response product, code signing is critical. The one we use sometimes complains even when the executable is signed with a valid certificate. It is a pain in the rear. But it is essential due to the number and sophistication of cyber threats today. Two-factor or multi-factor authentication is also a pain that I have to put up with daily. I can't do my job without my phone. The Internet is a tremendous resource. But there are days that I miss the simplicity of 8-bit computing.

Although that probably does not affect Delphi apps that use zlib. CVE-2023-45853 was a vulnerability in the minizip code in the contrib folder, not the zlib source.

That's an odd opinion, considering that a "pointer variable" or object reference with a nil value still results in an Access Violation if used before it is assigned a valid (allocated) memory reference. Using a local pointer variable before it is assigned a value is an error, regardless of whether the variable "defaulted to NIL". As Stefan stated, by not defaulting a value, the compile will give a warning (which I change to an error for every project). This code would not give a warning (silly example, but still): var MyForm: TForm := nil; MyForm.Show;

There is a lot of information and documentation available about string handling in Delphi. Here are two quick references: http://www.delphibasics.co.uk/ByFunction.php?Main=Strings https://www.thoughtco.com/string-handling-routines-delphi-programming-4092534 And here is a very basic solution to your request. Your actual purpose may be different from your description, but this code does what you asked: var str := '''abc'''; WriteLn(str); if str[1] = '''' then Delete(str, 1, 1); var last := Length(str); if str[last] = '''' then Delete(str, last, 1); WriteLn(str); ReadLn;

Between work and hobby, I use Delphi 11.3 over 50 hours a week, every week. I have half a dozen add-ons and over two dozen third-party component libraries installed, in addition to my own component library. When I started using Delphi 11.0 in July 2024, I experienced severe instability issues. Crashes or lockups at least once an hour. I had to restart the IDE after every single debug session. Many access violations during use or when closing the IDE. All those issues were caused by two Parnassus add-ons that I had installed via GetIt. Delphi has been stable for me ever since I uninstalled those two add-ons. I get an occasional exception in the IDE, maybe once a week. I use Visual Studio 2019 and 2022 much less frequently. My experience with VS 2022 is less stability than my Delphi 11.3 environment, and I only use VS 2022 a few hours a month. I have not had any stability issues with VS 2019 that I have with VS 2022, with the same third-party packages and add-ons installed in each.

Any code executing in the IDE can stomp on other memory allocated by the IDE. Any code executing in the IDE can corrupt the stack of any thread running in the IDE. If the component wrapping the DLL needs to load the DLL at design-time, there are plenty of ways that a C++ DLL executing in the IDE's process could cause IDE instability.

As been said elsewhere, most of us have a stable IDE environment. As long as the Delphi IDE executes code that is written by a third-party, there will be a chance that a third-party component or expert is the cause of instability. And in some cases, the user is the cause. I've written components that were buggy and caused instability until I took the time to find the defect and correct it.

The only way to avoid buffer overflow problems is to write code that doesn't overflow buffers. That won't change with a 64-bit IDE.

I have gone through all of the usual troubleshooting. Sadly, I've been fighting this for three hours... Delphi 11.3 I installed SVGIconImageList 3.9.6 (built for Win32 and Win64) sometime last year. I believe that I initially installed it from GetIt. At some point, I updated to 4.0.0 but only built packages and DCUs for Win32. Now I need it for Win64 and cannot get SVGIconImageList.dproj to build for Win64. I completely cleaned all files and registry entries related to SVGIconImageList. There was no trace of it anywhere. I downloaded the latest from the github repo and I'm having the same issue. All packages build for Win32. SVGImage32Package builds for Win64 without hints or warnings. SVGIconImageList refuses to build for Win64, with the compiler spewing two errors: [dcc64 Fatal Error] SVGImage32Package.dpk(31): E2225 Never-build package 'rtl' must be recompiled [dcc64 Fatal Error] SVGIconImageList.dpk(38): E2202 Required package 'SVGImage32Package' not found All packages are marked Explicit Rebuild. In 28 years, I've never seen Delphi complain that a rtl or vcl package must be recompiled. If I alter the order of the required system packages (rtl, vcl, vclimg), the fatal error complains about the package that is listed first under requires. Note the first error message is SVGImage32Package.dpk, which I believe is why the second error is listed. I've confirmed there are two SVGImage32Package.dcp (and bpl) files locatable via the system path. If I delete the Win32 packages and then try to build the Win64 packages, the compiler/IDE complains with this: [Fatal Error] C:\D11\Components\Packages\SVGImage32Package280.bpl cannot be added to the REQUIRES list of this package Note that C:\D11\Components\Packages\ is where the Win32 bpl/dcp are located when the Win32 packages are built. The Win64 files are in C:\D11\Components\Packages\Win64\. Any suggestions?

I would use Visual Form Inheritance for this, and place the "process form here" logic in the base form. If that isn't ideal, please give a better description. "modify forms on the fly" and "modify forms the moment they are created" are not the same. If you want to use an event, you could add a new event to your base form and implement the event in each derived form. You'd need to figure out when to assign the event so it would be executed by the base form's code when each form is created. I can think of a couple options, depending on your actual use case.

That would be useful. Or the ability to select which property changes you want ignored. The main downside would be remembering to turn off the "lock" when I intentionally make changes that I want to save. I use Beyond Compare before every commit and I'm in the habit of undoing unwanted or accidental form changes. I have been for over a decade now.

This was a constant issue for me. Doing nothing other than opening a form and closing it would prompt me to save changes and update component positions in the DFM. Until I started using DPI Unaware mode (bds.exe "/highdpi:unaware"). Now it never occurs.