[Lazarus] fpGUI

[michael.vancanneyt at wisa.be]

On Mon, 17 Jan 2011, Marcos Douglas wrote:

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

I don't have to. But 80% of the functionality returns.
This 80% is taken care of. The rest is business logic.

> - If you try predict all, you will have a BIG class (Custom Form);

Not really.

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

Totally wrong approach.

You create a form Save() method, NOT virtual, and add a OnSave event. 
That is the RAD way. If you add hooks in the right places, there is 
no need for endless descendants. We have 2 forms:

TAppForm
TDBAppForm (DB-Aware)

That's it. 95% of all forms descend from TDBappform. 
The rest descends from TAppForm.

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

That depends on your definition of big.

The form class together with all it's 8 auxiliary classes takes 2300 
lines. I don't think this is big.

And you make a common mistake: you try to do everything in OOP in 
the parent class.

I don't propose to do that at all.

I take the recurring tasks, and make sure we don't need to spend
time on them, so we can focus on the tasks which are specific in 
each form. Furthermore, each of these tasks can be customized by 
some event handlers to take care of special situations.

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

Never. Not with 4000+ form files. I suggest you try it.

What is more, if now we need a new functionality in all our forms,
I introduce it in the form class, and all our forms now automagically have
this functionality. This has happened numerous times in our application.

If your application has only 20 forms, all this is not worth it.

But when I started, I knew that there would be lots of forms, and an
application that would evolve over 10 years.
I did as I described here, and this has saved us huge amounts 
of time. The whole team and management here agree on that.
(one of the few things management and developers agree on ;-) )

Michael.