[Lazarus] fpGUI

[Michael Van Canneyt]

On Sun, 16 Jan 2011, Graeme Geldenhuys wrote:

> On Sun, 2011-01-16 at 07:29 +0100, Martin Schreiber wrote:
>> The separation of code and user interface definitions has advantages.
>
> Huh? The code describing the UI is just that UI code. My businsess
> objects and businesses rules are not located in Form units either. One
> of Borlands bad design ideas with RAD - as far as I'm concerned.
> Embedded business logic inside form units - something Delphi and Lazarus
> IDE's promote.
>
>> Graeme probably will encounter the limitations of his approach when he tries
>> to implement more sophisticated RAD possibilities into fpGUI. Visual form
>> inheritance and submodules (TFrame) come to mind for example.
>
> I already support the "frame" idea without problems. I can even have
> multiple forms in a single unit - something neither Delphi, Lazarus or
> MSEide can do.

This is not inherent to using resources, that is simply a design decision.
Keep it simple is a good thing.

What makes resources a good idea is
- Easy Visual Form Inheritance.
- Translation.
- Memory use.

When translating, you typically not only translate strings, but also shift 
controls (texts in dutch tend to be longer than their english equivalents). 
When using resources, this is done in 1 go, and you overload the original 
resource with the new one.

The code to construct the form is always in memory as soon as the binary 
is loaded. Resources are left on disk till you explicitly need them. 
They can even be in a DLL that is loaded on the go (as done for translations).
You cannot do this with "code constructed" forms. 
(maybe it could be done with packages).

All design decisions have their reasons.

Michael.