>
> I would generally create a single exported function in the DLL that
> would do the creation of the form, and that was the function called by
> the EXE - its only parameters begin for the mainform reference (to be
> used as owner) and reference to a structure containing other useful
> information.

That's exactly what i'm doing :)

>
> I setup a TList of special library access records to keep track of
> what DLLs I had openned and me to release them when no longer
> required. When a DLL form was created it would increment a reference
> counter in the associated TList entry, when destroyed it would
> decrement the reference counter.
>

I'm calling
Action=caFree;
in forms Close() method to let Borland to free whatever is needed.
In DLL I have static variable that will be set to true if form is open and
false when its closed.
If it's true, I just call
MyForm->BringToFront();

>
> Well I would share the entire connection (since we are not
> multi-threading) not just the handle - since there may be signifcant
> resource advantages depending on how you use your connection. I
> almost always have a transaction on the form itself, since I almost
> always consider a form to represent a unit of work.
>

From Jason:"I recommend that you do not pass an object reference from the
EXE to the DLL"

> The old version of the program that used the approach I describe, has
> been used every day for over 9 months by about 30 users without any
> dramas relating to DLL implementation. The new version of the program
> is moving away from DLLs and runtime libraries (I used both) and
> almost all forms come from the database itself.

How can you store forms into database?

>
>
> Geoff Worboys

Riho-Rene Ellermaa
senior programmer
Hansabank