[fpc-pascal] TFPColor vs TColor

[Graeme Geldenhuys]

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.


> One unit to rule them all ...
> I guess, the code observer will give a lot of hints for these files. ;)

Oh yes it does. I tried to add exclude rules but gave up after a while.  ;)


> Do you know that the lrs files can now be deleted? Lazarus can auto
> create them in the output directory.

I read something like that a while back. Very handy.


>>  * Not all form / component properties in the form need to be
>> published. I like my components and event handlers private and only
>> surface what is truly needed. It's called good OO design. ;-)
>
> Can you give an example?

It's just a pet peeve of mine when I see code as follows:


  lvar := EditUserForm.edName.Text;


Compared to:

  lvar := EdituserForm.UserName;

In the first example, I need to know the form instance name, component
name and property name of that component.

Not to mention every label, panel, groupbox etc are visible to the
world. I don't design a business object model like that (all
properties default as published), so why must I design my forms like
that?

Then again, the forms in my applications are completely empty
(almost). They are pure visual display of business objects. If I want
to access the Username, I rather do it via the business class and not
the GUI layer. What would happen if I wanted to create a web version
of that rich client application. No code in the GUI layer, means a
much quicker port to a web version.  But hey, now I'm drifting to
another topic here.


> 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. ;)

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 ]==================


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.


> So it rewrites the whole sections. That avoids a lot of problems.

Yes.

> How much 'pascal' does the reader understand?
> IFDEFs?

No

> Expressions?

No, unless the property is one of the "unknown" properties, then it works fine.

> With statements? Nested with statements?

Partial... The form designer generates with statements as a start - it
looks neater and I don't have to debug that code (tooltip debugging
doesn't support with statements).

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;

=====================================


> What about datamodules?

I don't use them. I use tiOPF for database applications.

> What about VFI?

No, but I do have forms that reuse frames (embedded forms).


Like I said, the fpGUI UI Designer is crude. It was simply to help me
design forms visually because hand coding them took to long. It is a
stop-gap until I can implement MiG Layout Manager. I have no intention
to implement yet another full-featured form designer or IDE. Lazarus
IDE already works perfectly for me.


> 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.


Regards,
  - Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/