[fpc-pascal] TFPColor vs TColor

[Mattias Gaertner]

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

> On Tue, May 5, 2009 at 1:36 PM, Mattias Gaertner
> <nc-gaertnma at netcologne.de> wrote:
> >
> > No.
> > Only the widgetset independent LCL properties are set. The LCL
> > interfaces then reads/sets the widgetset properties.
> 
> Thanks for explaining...
> 
> 
> > fpgui needs published properties when you want to edit components
> > visually. At the moment lazarus has designers for lcl TFrame, lcl
> > TForm and fcl TDataModule. Maybe someday you want to add a designer
> > for fpgui forms. hint, hint ;)
> 
> What would be the benefit of having a Lazarus form designer for fpGUI
> compared to fpGUI's own UI Designer? Would such a form designer
> generate non-LCL code?

If you mean the pascal code: Yes. 
The code generation works with TPersistent and TComponent.

If you don't like the lfm format, write a TReader/TWriter for your
format.

 
> fpGUI's own UI Designer works quite different to Lazarus's TForm form
> designer in that it generates Object Pascal code instead of LFM files
> (this was my personal preference). 

Yes, this has the big advantage of better smart linking and that the
compiler checks the properties.
It has the disadvantage that programmers will more likely try to
edit it. Does the fgui designer keep user changes or will it rewrite
the whole file every time?
I was thinking about writing a TReader/TWriter for pascal code, but it
has low priority at the moment.


> I can also have multiple forms in a single unit,

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 can handle unknown properties (properties not
> registered with the form designer - I still need to implement RTTI
> automated property detection) etc... 

Ehm, this sounds as if you don't use RTTI for streaming.
How does the fgui designer work?


> Make no mistake, the fpGUI UI
> Designer also has plenty of limitation, but it's more than capable
> enough for what I needed. It's quicker than designing a form layout by
> hand - that's until I get around to completing the MiG Layout Manager
> implementation.

:)

 
> > The object inspector, property editors and component editors work
> > with TComponent, so they already work with fpgui forms/controls.
> 
> Yeah, I made sure I keep to the TComponent style of design - simply
> because you don't know what you want to do in the future. Maybe I need
> form streaming somewhere down the line.  ;-)

Mattias