Well,

it is definitely a nice idea to stream a complete dfm into a table, but how
to recreate the components again at runtime??
I am an intermediate programmer, and I don't think, that I can create a form
at runtime with a dfm only without recreating the delphi-compiler and
include it into the app. Perhaps you can show me the way this is possible,
always keen on learning new techniques

If a base-form is designed well, and the data-access is layered into some
sort of BO (only a very minimalistice and simple approach), you won't need
much event-handlers in the app. For recurring tasks have preprepared generic
methods to access from the individual forms.

So, 70 BPLS or dll's won't be neccessary at all.....
Have all 70 forms of the app defined as row in a Rep_Forms-table with name
and base-form to use....
Create the base-form and follow the master-detail relations of the
form-definition to stream into the queries and their properties to define.
This is all handled at runtime with no BPL at all....
Create Data-awares at runtime and position them accoring to stored positions
in the DB...and assign them to the proper datasource and field.....still no
bpl or dll
Create IBO-Bars and have them either point to the datasource or have them
receive the focus....still nothing external invoked.
Create Reports...no problem...having report-designer liek Report-Builder,
you can store the report-definition also into the database and create it at
runtime.....
Create non-db-functionality.....load a bpl or dll NOW and you're off.....
And writing a second app (not that hard, also) to read and write to the
repository, all forms can be created without writing a line of code in
delphi, after the framework is finished...and handing out this app to the
customers, they will be able to customize the app themselves.....

I hope, you now got my point.

CU, Kaputnik
(Nick Josipovic)

nick@... <mailto:nick@...>
kap@... <mailto:kap@...>
-----------------------------------------------------------------------
superior Client/Server programming:
www.IBObjects.com <http://www.ibobjects.com/>
a nice Tool for Interbase:
www.InterbaseWorkbench.com <http://www.InterbaseWorkbench.com>

> -----Original Message-----
> From: Brian Nuckels [mailto:bnuckels@...]
> Sent: Friday, January 19, 2001 3:56 PM
> To: IBObjects@egroups.com
> Subject: Re: [IBO] Many applications and one connection
>
>
> I'm not sure I understand why you say to do this (below). Why not stream
> the entire DFM into the database field, then you don't have to separately
> create the controls either? Maybe I'm misunderstanding.
>
> The one drawback to this methodology is handling events is trickier. This
> is where scripting can help.
>
> If you go with the BPL route (which will be what you want to use
> instead of
> DLLs so you can share application resources more easily) then
> just make sure
> you link them dynamically! 70 DLLs in memory could be fun!
>
> ----- Original Message -----
> From: "Josipovic, Nick" <nick.josipovic@...>
> To: <IBObjects@egroups.com>
> Sent: Friday, January 19, 2001 3:11 AM
> Subject: RE: [IBO] Many applications and one connection
>
>
>
> > For the interface, you can use also a list of controls ot
> create and where
> > to position them.....this is the way, almost all customizeable
> big systems
> > are running.
>
>
>
>
>