Share Database/Session with dll

[Schatz GmbH, Abt. TEE]

Hi!
We are developing a modulized application with data input/output forms
provided in dynamicly loaded dlls. We connect to an interbase Database
using Queries.

The first problem was, that, without manipulation, every dll uses its
own attatchment and therefore one Interbase license, which was not
acceptable.
So we passed the global variables Session and SessionList (and
Application + Screen) to the dll, saving the dll's own variables and
switching them to the application variables.
That solved the attatchment problem.

The major problem still is:
Viewing the data should run within the default-session, so no additional
attatchment is needed.
Editing the data should run under transaction control, so we create a
new Session and a new database connection within this Session and link
all Queries to this new connection. This works fine within the
application (Query ... close, DataBaseName := , SessionName := , open),
but the attempt to switch the Queries created by the dlls ends up in an
exception similar to 'operation not supported on open datasets'.
I tried to debug the responsible code, and the thing I found is that the
code executed from the Query.close command differs between application
and dll.
The code executed within the application leads to a 'SetDBFlags' method
wich set FDataBase := nil, whilst the code executed by the dll leads to
some BDE callback functions not affecting the FDataBase variable,
resulting in the above mentioned exception when attempting to assign a
new database to the Query. There is no clue at which point and on which
settings the decision
between this two ways is made, since parts of Delphi, esp. BDE.pas, are
not included.

So are we completely on the wrong way, is it a BDE-bug or did we simply
forget to pass one vital global variable to the dlls?

Many thanks in advance for any helpful advice,

Rainer Leopold

[Jeff Overcash (TeamB)]

Have you considered using a BPL istead of a DLL? A BPL automatically shares the
VCL globals with the EXE (a major difference than a DLL) and makes using VCL
objects much easier.

"Schatz GmbH, Abt. TEE" wrote:

--
Jeff Overcash (TeamB)
(Please do not email me directly unless asked. Thank You)
Anyone who cannot cope with mathematics is not fully human.
At best he is a tolerable subhuman who has learned to wear
shoes, bathe and not make messes in the house. (Heinlein)

[Rainer Leopold]

"Jeff Overcash (TeamB)" wrote:

> Have you considered using a BPL istead of a DLL?

Hi Jeff ,

indeed I did, but I haven't found a satisfactory way to load DPKs at runtime in a
varying
selection (depending on how many DPKs/DLLs delivered to the customer).
Delphi help just mentions the possibillity of dynamic loading, but no further
information
on how to access them is given.
The second problem is that detailed structure of some those DPKs/DLLs is not defined

right now, apart from a naming convention and the 'exports' list.

But, as far as I understood the concept of DPKs, they not more then DLLs with a
Delphi
generated 'exports' list, so every feature of DPKs should be available by DLLs as
well?

Regards,
Rainer Leopold

[Karlheinz Spaeth]

Rainer Leopold wrote:

> But, as far as I understood the concept of DPKs,
> they not more then DLLs with a Delphi generated 'exports' list,
> so every feature of DPKs should be available by DLLs as well?

No. BPLs are much more easier to use than DLLs. I am building an application
that dynamically loads packages. They add UI functionality to the main
program, which is only 23 KB. You use data in other packages as easy as
using components from the palette. This is far better than DLLs, where you
are very limited in importing/exporting classes.

Gruß, Karlheinz

[Guillaume Hrdy]

May you show us some example of UI adding via BPLs, since i'm pretty newbie to
dynamic loading with Delphi ?

Regards

Karlheinz Spaeth a écrit :

--
____________________________________
Guillaume HRDY
E-mail : eurely...@lemonde.fr
Phoenix Suns rules !
____________________________________

[Schatz GmbH, Abt. TEE]

> Hallo Karlheinz, hi Guillaume

the problem of loading BPLs dynamically at runtime is :
the whole classinformation of classes provided by the BPLs must be known at
compilation time. So there is now way to plan for the future..
Just a simple test:
Assume you have a Form defined in Unit2:
TForm2 = class(TForm)
.....

initialization
RegisterClass('TForm2');
finalization
UnregisterClass('TForm2');
end.

and you build a BPL 'Unit2Pack.bpl.'

Accessing TForm2 by a button-click within an application :

.....

uses
Unit2; // important !

procedure TForm1.Button1Click(Sender: TObject);
var
DynClass: TDynClass;
Module : HMODULE;
begin
try
Module := LoadPackage('Unit2Pack.bpl');
DynClass := TDynClass(GetClass('TForm2'));

with DynClass.Create(self) do
begin
ShowModal;
Free;
end;
finally
UnLoadPackage(Module);
end;
end;

works fine as long as unit2 is mentioned in the uses list.
Either deleting unit2 from the list or supressing the call of 'RegisterClass' in
the initialization part of unit2 will lead to a nil pointer returned by
GetClass!

(The call to RegisterClass at runtime within a bpl / dll registers the class to
the
dll's private classlist, not to the application)

Regards,

Rainer Leopold