[fpc-pascal] TFPColor vs TColor

[Mattias Gaertner]

On Tue, 5 May 2009 17:10:01 +0200
Graeme Geldenhuys <graemeg.lists at gmail.com> wrote:

> On Tue, May 5, 2009 at 4:21 PM, Mattias Gaertner wrote:
> >
> >>  * If a component changes, a simple "search and replace" can fix
> >> all your code.
> >
> > This works in lfm too, doesn't it?
> 
> I don't know, Delphi didn't. Does it search LFM's when you do "Find in
> Files" and select "all files in project"? I thought it doesn't. I
> meant search and replace all files in a directory or all files part of
> a project - not just the current file in the editor.

I use Find in files in a directory for that.

 
>[...]
> > Why write a sophisticated hiding when you can avoid all the problems
> > and put it into a separate file? See below.
> 
> That's actually true...  I got the idea from Visual Studio and C#
> which folds the auto-generated form designer code by default. But then
> Visual Studio does use include files. ;)

And yet another reason for not using Visual Studio for inspiration.

 
> But then again, if you use include files you might need two of them.
> One for the Interface section and one for the Implementation section.
> Or roll them into one, but then you have to use some IFDEF trickery as
> follows...
> 
> Interface section...
> 
> { This lets us use a single include file for both the Interface and
>   Implementation sections. }
> {$define read_interface}
> {$undef read_implementation}
> 
>     {$IFDEF DUnit}
>       {$I DUnitCompatibleInterface.inc}
>     {$ENDIF DUnit}
> 
> Implementation section....
> 
> {$undef read_interface}
> {$define read_implementation}
> 
>     {$IFDEF DUnit}
>       {$I DUnitCompatibleInterface.inc}
>     {$ENDIF DUnit}
> 
> .... and then the include file
> 
> ============[ DUnitCompatibleInterface.inc ]==============
> {%MainUnit fpcunit.pp}
> 
> {$IFDEF read_interface}
>     class procedure Check(pValue: boolean; pMessage: string = '');
> {$ENDIF read_interface}
> 
> 
> {$IFDEF read_implementation}
> 
> class procedure TAssert.Check(pValue: boolean; pMessage: string);
> begin
>   AssertTrue(pMessage, pValue);
> end;
> 
> {$ENDIF read_implementation}
> ==============[ end ]==================

There are ways to use a single include file. For example:

---------
{$I unit1.lfm}

constructor TForm1.Create(TheOwner: TComponent);
begin
  RegisterComponentInit(@InitTForm1,TForm1);
  inherited Create(TheOwner);
end;

--------
unit1.lfm:
procedure InitTForm1(AComponent: TComponent);
begin
  with AComponent as TForm1 do 
  begin
    Name := 'Form1';
    Caption := ...
  end;
end;
---------

No interface, no intialization. Good for smart linking.


> Also if you use a source code management system like SVN or Git, it
> means your form history is now split over multiple files and not a
> single file. Though I guess this is not a major issue really.

It's not even a minor issue.


>[...]
> Here is some sample code written by the form designer...
> 
> =====================================
> procedure TSystemLocksForm.AfterCreate;
> begin
>   {@VFD_BODY_BEGIN: SystemLocksForm}
>   Name := 'SystemLocksForm';
>   SetPosition(310, 242, 397, 256);
>   WindowTitle := 'System Locks';
> 
>   grdLocks := TfpgStringGrid.Create(self);
>   with grdLocks do
>   begin
>     Name := 'grdLocks';
>     SetPosition(8, 8, 381, 208);
>     Anchors := [anLeft,anRight,anTop,anBottom];
>     FontDesc := '#Grid';
>     HeaderFontDesc := '#GridHeader';
>     RowCount := 0;
>     RowSelect := False;
>     TabOrder := 0;
>   end;
> 
>   btnRemove := TfpgButton.Create(self);
>   with btnRemove do
>   begin
>     Name := 'btnRemove';
>     SetPosition(8, 224, 92, 24);
>     Anchors := [anLeft,anBottom];
>     Text := 'btnRemove';
>     FontDesc := '#Label1';
>     Hint := '';
>     ImageName := 'stdimg.remove';
>     TabOrder := 1;
>     OnClick := @btnDeleteClicked;
>   end;

How are images and other arbitrary data saved to the source?

 
> =====================================
> 
> 
> > What about datamodules?
> 
> I don't use them. I use tiOPF for database applications.

I meant links to other forms/datamodules/frames:
  DBText1.DataSource:=Form2.DataSource1;

 
>[...]
> > I vote for an include file. This way the reader/writer can work
> > even if there are errors in the unit. Just imagine, you want to
> > save your work and the IDE tells you have to first fix your code.
> 
> True, but fpGUI UI Designer already ignores everything outside the
> comment markers. So if the rest of your code doesn't compile, you can
> still edit your forms.

The 'markers' solution is nice for small things. But

*The lfm files can become quite large. Just put 100 components onto a
form and add some glyphs. There will be several thousand lines of
automatically generated code in your unit.

*When you now use Search/Replace, you will almost always run into
trouble.

*Word completion will show you a lot of junk.

*when the IDE searches a component with the name 'Form1' it has to
read in worst case all source files in the search path completely. This
can take on a slow system a minute. With separate files it can just
search for lfm files and read the first line.


Mattias