On Tue, 5 May 2009 17:10:01 +0200
Graeme Geldenhuys <graemeg.li...@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
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
