dummzeuch

No, it doesn't say anything about the reason, just crashes and I get the Windows error dialog.

Not so impressed: Installation worked fine and was fast, but ... The Web-Installer installed to c:\program files (x86) even though my 10.4 installation was somewhere else. When the IDE started with my custom layout (which is not a floating designer layout), I get an AV in rtl270.bpl. The same happens when I try to switch to that layout later. Trying to load any existing project crashes the IDE I'll do an uninstall and try again, this time trying to not miss the option for a custom installation path. I seem to remember from other installations that there was one. Edit2: Uninstalling, deleting the Registry entries and also deleting the old installation directory fixed both crashes. Edit3: Missed the option to select a custom installation path three times. It's here:

Interesting, I didn't even know this exists. Now that I do, I found that Steve Trefethen blogged about it in 2005: Command line option to display menu item names in Delphi 2006

I'm not sure whether I'd care much about Delphi projects when my house burns down. But on the other hand, I don't have a house, I live in a rented flat, so maybe I would care.

Maybe virtualization is causing the slow down the original poster is talking about? I never install anything to program files, that wants to write to its installation directory. Virtualization has bitten me to many times.

Delphi 7 was released in 2002! You're thinking about Delphi 2007.

I'm pretty sure it didn't. If was released only a few months after Windows XP.

Some configuration files, as Lars said. Edit: I just checked: It's the .dst files which store the desktops and a delphi32.dsk file which stores the recently used files and other information.

Program Files is handled special by Windows 10, so changing the permissions might still not be the same as using a different directory. I'm not saying that's the cause, but it might well be it.

I have not noticed any slow down in D7 compile speed when i upgraded my development computer from Windows 8.1 to 10. What stands out about your installation though is that it is located under "program files (x86)". Mine isn't because D7 writes to its installation directory. So maybe that has something to do with the slow down you experience?

Isn't a single line edit part of synedit?

As far as I remember with packages it's the same as with units: If you don't change the interface section, you don't have to recompile depending units. For packages the dcp file contains the interface sections of all units in the package.

TDbf is an open source library to access Dbase tables. It's released under the LGPL license (which makes in impractical for most commercial Delphi development). It is also used in Lazaraus (I haven't checked the license there, but apparently you can develop commercial programs with it.) The project seems to be rather dead though. Apparently nobody noticed ... https://blog.dummzeuch.de/2018/12/26/tdbf-packages-for-delphi-10-3-rio/

I just created packages for Delphi 10.4 by copying and adapting the Delphi 10.3 packages. I also added it to the include file. I did this using a text editor, because I currently don't have access to a Delphi 10.4 installation. That means that I cannot test whether it compiles and works. Please update to the latest sources, open the Delphi 10.4 group project and try to compile the packages. Please tell us whether it worked.

No, this would mean that somebody could create a plugin for a commercial program (of a third party) and release it under the GPL. And then this would force that commercial program to also fall under the GPL. But we degress, this is about the MPL, which is a lot less strict.

The MPL only requires you to provide the sources that are licensed under the MPL, unless you modify the original. In that case you must also make those modifications available. It does not require you to make the sources of your program available. It also doesn't matter whether or is linked into the executable or called as a DLL, so no need to isolate it as a DLL. (Disclaimer: I'm not a lawyer. This is how I understood the license text.)

No, it wasn't removed, it works for me. No idea why it doesn't work for you though. If i remember correctly there is a setting to turn it off, but the default is turned on.

Maybe one of the first things somebody could contribute, are English translations of the comments then. 😉

That "Python project" is PyScripter, one of the most popular IDEs for Python developments. GitHub makes branching so easy, everybody and his brother seems to create his private branch of basically every library in existence, which makes it difficult to see if there is such a thing as an "official" repository. So, welcome to branching hell. 😉 Which version you chose might depend on how much you need / value backwards compatibility. Last time I looked, SynEdit was backwards compatible to at least Delphi 6, SynEdit-2 only to some XE version. SynEdit-2 focuses more on keeping up with the latest Delphi versions.

It's probably just a matter of adding a conditional define to some include file. Maybe - probably at some time in the far future - I fill find the time to future proof the include file to not require an update every time a new Delphi version is released.

The Help has the following to say about System.GetMemory: From that description, I assumed that this function raises an EOutOfMemory if it cannot allocate a block and so I don't need to check whether it returns NIL. Apparently that's wrong. My program just requested a block of 35880960 bytes (for the 50th time, yes that makes 1.7 gigabytes and it's quite possible that it run out of memory) and the function returned NIL on this call any any subsequent calls with that size. Am I missing something here?

No, it's not. There are at least two actively developed forks on GitHub: https://github.com/SynEdit/SynEdit https://github.com/pyscripter/SynEdit-2 The first one is the "Original". I use it GExperts for all Delphi versions from 6 upwards.

The nineties called and wanted their sort indicator back. I'm sure I must have code for that somewhere. It was pretty common back then.

Please file a bug report on sourceforge if you have not already done so.

I'm not aware of any tool that allows this. And I don't know the mechanism behind it. Is there a menu entry that does the same? If yes, you could assign a keyboard shortcut to it.