Leaderboard

While I see what your getting at, this feature kind of already exists if you right click on the project, not the folder. When you add a new unit, it creates a dirty buffer that has not yet been saved. Saving it prompts you for the name, which defaults to unit1.pas (or next available number) in the project directory. In the save dialog its trivial to click on a folder (or create a new one) and save it there instead. The first thing I generally do when I create a new unit is save the file and give it a proper name and location. The folders don't show up until you add a file that is in a folder other than the dproj project folder location. As far as adding multiple existing units from a directory, I just drag and drop from explorer to the project and it "automagically" puts them in the appropriate folder (based on the existing location of course). Much simpler than clicking the button or right clicking to add to the project, unless its a one off.

You are using it for free. What ever they decide to do with her work is only up to them. Why do you think there are rights on your side? For sure the communication could be better. But... use a commercial version and be a customer and not a consument....

Assuming you are using the Turbopack Synedit: Changes to the text buffer are undoable. So just calling Delete does not clear all related memory. You need to do one of: call ClearUndo every now and then to release the undo/redo memory. Set MaxUndo to some number to limit the undoable actions. The default is 0 (unlimited undo/redo). call LockUndo/Unlock undo to prevent actions being added to the undo/redo stack (the most efficient). If you still get a memory overflow then this is a bug that you should report.

A generic TStream has no idea how to store data, it is just an abstract class. Therefore any data written to it after this code snippet: are simply discarded. I'd replace the first line with this: ms := TMemoryStream.Create; The variable declaration can remain the same.

Many have struggled with VCL Styles since they were introduced. They may work in simple cases, but I have personally lost a number of hours of dev time due to this issue. I would try to set the .UseParentPaintBuffers property to True and re-test your style flicker. There is a little info on it at the bottom of this page: https://docwiki.embarcadero.com/RADStudio/Sydney/en/VCL_Styles_Support_for_High-DPI_Graphics

I had a similar issue. If I remember well, setting the ParentBackground property to true for all controls helped, although I see in the previous thread that @Uwe Raabe claimed the opposite. There was such an issue https://quality.embarcadero.com/browse/RSP-31158 that is supposed to be fixed in D11. See also the related issues to this one. See also TStyleManager.UseParentPaintBuffers introduced in D11. I have not tried it and there is limited documentation.

I'm happy it worked for you. Maybe you should do a full Delphi reinstall ?

Emb must attract new users, however it's include not only lower price for SKU but also compilation for linux in CE edition. As almost all solutions are written for linux. Share of delphi in open source is miserable.