[Lazarus] fpGUI

Marcos Douglas md at delfire.net
Mon Jan 17 12:55:36 CET 2011


On Mon, Jan 17, 2011 at 7:03 AM,  <michael.vancanneyt at wisa.be> wrote:
>
> [snip]
>
> I have an application with 1500 forms. It would be madness to have to set
> over and over again the same set of properties and event handlers to
> save/restore formlayout, ask to save unsaved data, sort grids and whatnot.
> So
> - You create a descendent of TForm (or TCustomForm)
> - You add all 'common' functionality to this descendant, plus lots of extra
>  properties to control this functionality.
> - You register this form in the IDE under File/New
> - You do the same for common controls. Grids, date edits, whatnot. You
>  register them on the component palette.
> - Create a wizard that creates an initial layout for the form, based on the
>  data you'll be editing in that form. (we use 3-tier data, but you can do
>  exactly the same for a persistence framework)
> [snip]

You have some problems with this approach:
- You can not predict functionalities for ALL forms decendents;
- If you try predict all, you will have a BIG class (Custom Form);
- The Forms decendents not will use all features of the CustomForm;
- Imagine you have a CRUD Custom Form. You have buttons to insert,
update, delete, save, cancel, whatever. You decide make a new Form
(inherite of YourOwnCustomForm). Every thing works, but you need 2
news buttons... The buttons shoud be sincronized with the buttons
state of CustomForm. But the method that make this is in CustomForm.
What you do? The method is modified to 'virtual' and you add more code
lines in NewForm to treat 2 new buttons... because the CustomForm not
predict everything... Exists others examples: the Save method should
do more things in
the NewForm, before save data... you have to create, in CustomForm,
the BeforeSave method (as virtual and your implementation is nothing)
just to have a entry point to descendent classes make your own
configurations... at the end, you have a BIG CustomForm class, don't
you?

> Since it is simply OOP, You could do all of this in code, but code is slower
> to create and is more error-prone. Hence RAD and point-and-click.

Slower? Not realy. You take a time to developer all widgets in your
company... so, the same time would be used to developer all code
without widgets, as Graeme did, e.g.

Marcos Douglas




More information about the Lazarus mailing list