PeterBelow

27 minutes ago, hsauro said:

Slightly off topic I know but what what is the rational for having immutable strings in languages such a Java, Python etc?

 

It seems immutability is related to efficiency and security. I didn’t find the arguments that compelling however. It seems it’s either to stop the programmer from getting into trouble or it makes like easier for the complier writer.

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

2 hours ago, Mike Torrettinni said:

I just couldn't make it work with var parameter, it kept giving me :  E2033 Types of actual and formal var parameters must be identical

So, I changed into a function:

 

function AccessForm2(aForm: TForm; aClass: TFormClass; aModal: Boolean = True): TForm;
begin
  if not Assigned(aForm) then
    Result := aClass.Create(Application)
  else
    Result := aForm;
  Assert(Assigned(Result)); // just in case :-)
  if aModal then Result.ShowModal else Result.Show;
end;

and I call it with:

 

Form2 := AccessForm2(Form2, TForm2, True) as TForm2;

Seems a bit complicated... am I doing something wrong?

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.