PeterBelow

What Delphi version are you using? In older versions the Application object was actually the one owning the taskbar button, all other forms used the (zero-size) window maintained by the Application object as API-level owner, and Window does not show taskbar buttons for owned windows.

It makes automatic memory management via garbage collection easier to implement and more efficient as far as I know.

There is one loophole in your design: if a form is destroyed it will not automatically set the form variable the designer created for it to nil. I can only stress what has been posted in some of the other replies: do not use the form variables for forms that are not autocreated! Delete the variable declaration directly after the form unit has been created by the designer. Use local variables for modal forms (or a class method to create, use, and destroy them). For modeless forms you can always find existing instances by looking at the Screen.Forms array, or have the main form (which presumably creates such a form on an as needed basis) keep the reference in a private field. The automatic form variables encourage some bad programming practices (like accessing controls on another form directly) and become worse than useless if you have to have more than one instance of a given form class open at the same time.

What is build into the VCL is the drag and dock support also used by the RAD Studio IDE, the "snap to border" functionality is something different. If none of these two features match your need you have to build you own, which you seem to have done now. Do you know you can use inheritance with forms as well? Build a base form class with the functionality you need, add it to any new project you need this functionality in and then create new forms in the designer by using File -> New -> Others, and pick the base class from the "inheritable items" section. Just changing the ancestor class from TFrom to your base class in the editor does not work directly, since forms have associated DFM files. You would also need to edit the DFM file as text and change the first "object" to "inherited" for this to work.

Via TStringHelper you have to first convert the string into an array of char, modify that, and then convert the array into a new string. var LChars: TArray<char>; LStr: string; begin LStr := StringOfChar('A', 20); LChars := LStr.ToCharArray; LChars[Low(LChars)+1] := LChars[Low(LChars)+1].ToLower; LStr := String.Create(LChars);

The default for the linker options of a debug configuration is to include debug information into the produced EXE. That massively increases the size of the EXE, and, if you are using the IDE debugger (for a 32 bit project), is also completely useless, since the IDE debugger gets the debug info from the DCUs, not the EXE.

You have to modify the design-time package that registers the property editor and rebuild it. Or just disable the package if you do not use any of the controls from it.

Instead of Projects: TArray<TProject> use a list class: type TProjectList = class(TList<TProject>) end; Add public methods to the class that implement your current for loops. This way you have all this code centralized in one place, which should massively simplify the maintenance. And while you're at it: convert the record into a class. Lists of records are a bit inefficient since accessing the items in the list involves a lot of copying of data. You can then use a TObjectlist<TProject> as base class for your TProjectlist and let the list manage the memory of the TProject objects you add to it (OwnsObjects parameter for the list constructor set to true, which is the default).

The source for the units that are actually compiled into the IDE packages is not available. You only have what is needed to write IDE extensions using the OpenTools API, and even that is not always complete. It may contain references to other classes or routines available through one of the IDE packages, though, but usually you are not meant to use them in your extensions.