[fpc-pascal] TFPColor vs TColor

[Mattias Gaertner]

On Tue, 5 May 2009 15:14:02 +0200
Graeme Geldenhuys <graemeg.lists at gmail.com> wrote:

> On Tue, May 5, 2009 at 2:30 PM, Mattias Gaertner
> <nc-gaertnma at netcologne.de> wrote:
> >
> > If you don't like the lfm format, write a TReader/TWriter for your
> > format.
> 
> I don't have issues with the LFM format, it's the extra file I have an
> issue with, plus a few others... see below.
> 
> 
> > Yes, this has the big advantage of better smart linking and that the
> > compiler checks the properties.
> 
> Correct. Plus the following...
> 
>  * If a component changes, a simple "search and replace" can fix all
> your code.

This works in lfm too, doesn't it?

 
>  * One unit contains everything. No need for .pas, .lfm and .lrs
> files.

One unit to rule them all ...

I guess, the code observer will give a lot of hints for these files. ;)

Do you know that the lrs files can now be deleted? Lazarus can auto
create them in the output directory.
And if you write a TReader/TWriter for pascal code, well, then lazarus
will not need the lfm/lrs files. Although I recommend to put the code
into an include file (see below).

 
>  * 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?

 
>  * No need for an automated global form variable.

Streaming does not need them.

 
>  * I can define forms or dialogs in the Implementation section as
> well.

That's even worse for error handling.

 
> > It has the disadvantage that programmers will more likely try to
> > edit it.
> 
> Hence the reason for feature request #13514. Regions that can be
> folded by default when opened in the editor, so I can hide the
> automated GUI generation code. If the developer knows what he is
> doing, then by all means allow him or her to edit the code manually.

Why write a sophisticated hiding when you can avoid all the problems
and put it into a separate file? See below.


> Who hasn't edited a *.lfm or *.dfm file every now and again. ;-)

Of course, that's why they are in text form.
But I fear if we support 'pascal forms' then the users will soon create
bug reports that it does not support the whole 'pascal' syntax
(e.g. expressions and constants, see below).


> Though Lazarus is a lot more tolerant when it comes to error handling
> compared to Delphi. :-)

:)

 
>   http://bugs.freepascal.org/view.php?id=13514
> 
> 
> > Does the fgui designer keep user changes or will it rewrite
> > the whole file every time?
> 
> I launch the fpGUI UI Designer from inside Lazarus IDE using the
> current editor file (setup via Tools menu). The designer keeps track
> of changes internally and only saves the file once, when the user
> selects "File > Save". Once your quite the form designer, you are
> return to Lazarus IDE, which that auto detects the file change and
> prompts for a reload. This works brilliantly. Lazarus IDE is great!
> The fpGUI UI Designer uses comment markers to know what to read and
> edit. Other code is not touched at all.

So it rewrites the whole sections. That avoids a lot of problems.
How much 'pascal' does the reader understand?
IFDEFs? 
Expressions? 
With statements? Nested with statements? 
What about datamodules?
What about VFI?

 
> > I was thinking about writing a TReader/TWriter for pascal code, but
> > it has low priority at the moment.
> 
> Interesting. Where would it save that pascal code? An external file
> (maybe an include file) or directly inside the .pas file?

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.

The include directive could be anywhere in the code.

 
> > Multiple forms per unit makes error handling much more complicated.
> > The one-form-per-unit concept is easy to understand and not a big
> > limitation. Just like the java one-class-per-file limitation.
> 
> I limit myself to one form per unit as well (in my own projects). It
> only came in handy when I designed the fpGUI standard dialogs in the
> fpg_dialog.pas unit (similar to Lazarus's dialogs.pp unit).

;)

 
> > Ehm, this sounds as if you don't use RTTI for streaming.
> > How does the fgui designer work?
> 
> No, it doesn't for streaming. :-) I only use RTTI to detect if
> properties of components contain non-default values. So I can limit to
> generated code. The UI Designer is crude, but effective for it's
> needs. It's not designed to be a Delphi or Lazarus form designer - but
> it's still very effective.
> 
> Each component I want in the form designer registers itself, what
> properties must appear in the object inspector and optionally and
> property hint. The properties that are not registered are still
> accessible in the object inspector via the "unknown properties" memo.
> For the latter you can't see visual change, but they will be there at
> runtime. Each property type (boolean, integer etc.) has a class that
> knows how to read or write object pascal code.

This sounds as if you have reinvented RTTI ...

 
> There also exists property designer for more complex properties like
> Columns in a StringGrid.
> 
> And in case I haven't registered a visual component with the designer,
> you can always fall back to using the special TOtherWidget component.
> When placed on a form it pops up and asks for the name and base class.
> You can then use the "unknown properties" memo to fill in any extra
> property values. A nice "catch all" feature. ;-)

... and you reinvented property and components editors.
I wonder what you would come up with if the world would stop wheeling
for a year. :)

 
> ==================
>   // ComboBox
>   wc          := TVFDWidgetClass.Create(TfpgComboBox);
>   wc.NameBase := 'ComboBox';
>   wc.AddProperty('FontDesc', TPropertyFontDesc, 'The font used for
> displaying the text');
>   wc.AddProperty('Items', TPropertyStringList, '');
>   wc.AddProperty('ParentShowHint', TPropertyBoolean, '');
>   wc.AddProperty('ShowHint', TPropertyBoolean, '');
>   wc.AddProperty('TabOrder', TPropertyInteger, 'The tab order');
>   wc.WidgetIconName := 'vfd.combobox';
>   RegisterVFDWidget(wc);
> ==================
> 
> So yes, I believe this is a very different design to what Lazarus IDE
> follows. Programming is great - a 101 ways to accomplish a similar
> task.  :)

Well, it looks quite familiar to me:

  RegisterPropertyEditor(ClassTypeInfo(TCustomPage),
    TCustomNotebook, 'ActivePage', TNoteBookActiveControlPropertyEditor);


Mattias