[Lazarus] fpGUI

Graeme Geldenhuys graemeg.lists at gmail.com
Mon Jan 17 11:48:52 CET 2011


Op 2011-01-17 12:03, michael.vancanneyt at wisa.be het geskryf:
> 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
[...snip...]
> 
> After that, you create new forms extremely fast without losing RAD
> functionality: a pure point-and-click environment, which is always
> faster than coding, and which is understood by people of many skill levels.


And our company does exactly that, but without the need of a specific
IDE's RAD functionality. Every heard of code templates? ;-)  I'm a
self-confessed code templates junkie! There, I said it! :) I can slap
together stax of usable forms or code, with functionality like
mediators, auto save/restore form positioning, localization etc all
enabled, simply by using a few of our designed code templates - and a
lot faster than anybody can drop components on a form & double clicking
to set event handlers etc.

Clearly each development team has their own way of working. There is no
right or wrong. I'm simply stating that "RAD" can mean many things to
many development teams. And the "RAD" Borland was marketing, by writing
a crap load of business logic inside form units, is NOT the way our
company works.

I learnt my lesson at a previous employer, after having to help maintain
a *huge* Delphi "RAD based" project. See my favourite URL of that
"brilliant Borland RAD idea" in action.

  http://opensoft.homeip.net:8080/~graemeg/datamodule.png

Just looking at it, makes my eyes tear. :)


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

Why error-prone? If you use well tested and developed code templates,
you end up with having consistent looking and tested code. eg: Taking
the tiOPF's MGM functionality as an example: We use StringGrid's a lot
in our products, but all the developer needs to do is drop a grid on a
form. No need for tweaking the grid's property settings etc. Then simply
create an instance of our StringGrid mediator, and the grid is done.
Instantly that grid gets all our preferred settings and event handlers
setup, plus customized painting etc... all my hooking up one mediator to
a stock standard grid component. Now if we wanted to update the look of
all our grids in our project, we simply have to modify our base
stringgrid mediator class, and recompile our project. Quick, easy and
consistent!


> Hence RAD and point-and-click.

Which could result in one form's Grid not quite behaving like the other
form's grid in the same application - because the developer forgot to
set all the right properties for the 100th time.


So RAD can have many meanings and implementations, depending on the
team. The mouse-style developer is not the begin-all, end-all of
software development.


Regards,
  - Graeme -

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/





More information about the Lazarus mailing list