Board index » delphi » DLL or Packages: Shared Classes? HELP!

Richard Carruthers

Delphi Developer
Tue, 17 Feb 2004 03:21:06 GMT

DLL or Packages: Shared Classes? HELP!

I have an app that I need to be modular, in that it needs to support
multiple DataEngine Objects. Each DataEngine is responcible for maintaining
a common interface (or course), but implement entirely different behavior. I
had the whole thing setup and working (I thought) until I hit this snag:

Main EXE uses Unit A, and GenericDataEngine Unit;

DLL creates a Descendant Class of GenericDataEngine, thus GenericDataEngine
Unit is included in the DLL uses clause.
DLL also needs to understand types (objects) from Unit A (as method
parameters), so it also includes Unit A in its uses clause.

Now this DLL procedure fails, even if OBJ is UnitAType:

Function IsParamMyObj(Obj:TObject):Boolean;
begin
  Result :=(Obj is UnitAType);
end;

I believe this is because the DLL and the App have different class
tables.... How can I merge them? Will using packages help? I don't just need
one or two classes, I need all the classes to be the same because I cannot
tell what classes the DLL may use.

Anyone have any Ideas... I'm pretty desperate here - my entire OO design
hangs in the balance here.

 
Franz-Leo Choms

Delphi Developer
Tue, 17 Feb 2004 04:20:12 GMT

Re:DLL or Packages: Shared Classes? HELP!


Quote
>I believe this is because the DLL and the App have different class
>tables.... How can I merge them? Will using packages help? I don't just need
>one or two classes, I need all the classes to be the same because I cannot
>tell what classes the DLL may use.

>Anyone have any Ideas... I'm pretty desperate here - my entire OO design
>hangs in the balance here.

Packages will help, since then both the DLL and the App uses the same
copy of the code.

If you still want to use the DLL version, you can check the classname,
if you can assure that it is unique, or you have to garantee that the
is operator is onyl used for classes created in the same scope, i.e.
you can only check classes in the application/dll which are created by
the application/dll.

If you use packages, you might have to rearrange the
units into smaller packages to reduce their size. I have runtime
packages which are twice as large then the application, since the
linker can't remove units and classes from packages.

Regards from Germany

Franz-Leo

Richard Carruther

Delphi Developer
Tue, 17 Feb 2004 04:39:48 GMT

Re:DLL or Packages: Shared Classes? HELP!


I am writing a test app to try this now, however... I Still dont see how
using packages will elliminate having 2 coppies of the class since the unit
will be used in the exe and in the package - Do packages link to the main
EXE's class table?

Quote
"Franz-Leo Chomse" <franz-leo.cho...@samac.de> wrote in message

news:dk7tot85p3i7pbfgppc3n1aotc4mdp42oa@4ax.com...
Quote

> >I believe this is because the DLL and the App have different class
> >tables.... How can I merge them? Will using packages help? I don't just
need
> >one or two classes, I need all the classes to be the same because I
cannot
> >tell what classes the DLL may use.

> >Anyone have any Ideas... I'm pretty desperate here - my entire OO design
> >hangs in the balance here.

> Packages will help, since then both the DLL and the App uses the same
> copy of the code.

> If you still want to use the DLL version, you can check the classname,
> if you can assure that it is unique, or you have to garantee that the
> is operator is onyl used for classes created in the same scope, i.e.
> you can only check classes in the application/dll which are created by
> the application/dll.

> If you use packages, you might have to rearrange the
> units into smaller packages to reduce their size. I have runtime
> packages which are twice as large then the application, since the
> linker can't remove units and classes from packages.

> Regards from Germany

> Franz-Leo

Terry Fiel

Delphi Developer
Tue, 17 Feb 2004 04:49:53 GMT

Re:DLL or Packages: Shared Classes? HELP!


Quote
"Franz-Leo Chomse" <franz-leo.cho...@samac.de> wrote in message

news:dk7tot85p3i7pbfgppc3n1aotc4mdp42oa@4ax.com...

Quote

> >I believe this is because the DLL and the App have different class
> >tables.... How can I merge them? Will using packages help? I don't just
need
> >one or two classes, I need all the classes to be the same because I
cannot
> >tell what classes the DLL may use.

> >Anyone have any Ideas... I'm pretty desperate here - my entire OO design
> >hangs in the balance here.

> Packages will help, since then both the DLL and the App uses the same
> copy of the code.

I agree that using packages is the way to go. I have been dealing with an
almost identical problem recently. I have rewritten my persistence mechanism
so that the concrete implementation is loaded at runtime after the backend
database type has been determined.

What I found I had to do was put my abstract persistence classes in one
package and each set of concrete persistence classes in another. Then I
built the projects using packages and specifying the abstract package in the
package list. You can limit the package list to that one only if you don't
want to distribute all the Borland runtime packages.

When the application runs, it loads the required concrete persistence
classes package using 'LoadPackage'.

Richard Carruther

Delphi Developer
Tue, 17 Feb 2004 05:08:39 GMT

Re:DLL or Packages: Shared Classes? HELP!


can you give me a generic example of this..

what I am looking for is a description of the process - such as:

1. Put Class A in Unit A
2. Use Unit A in Package A (Class holder package)
3. Use Unit A in MainApp.DPR (main exe)
4. Load Package A from with Package B (engine)
5. (MainApp.VarofClassA is Package B.VarofClassA) = true

Quote
"Terry Field" <ter...@nospam.symphosys.com> wrote in message

news:3b8ea6ed$1_1@dnews...
Quote

> "Franz-Leo Chomse" <franz-leo.cho...@samac.de> wrote in message
> news:dk7tot85p3i7pbfgppc3n1aotc4mdp42oa@4ax.com...

> > >I believe this is because the DLL and the App have different class
> > >tables.... How can I merge them? Will using packages help? I don't just
> need
> > >one or two classes, I need all the classes to be the same because I
> cannot
> > >tell what classes the DLL may use.

> > >Anyone have any Ideas... I'm pretty desperate here - my entire OO
design
> > >hangs in the balance here.

> > Packages will help, since then both the DLL and the App uses the same
> > copy of the code.

> I agree that using packages is the way to go. I have been dealing with an
> almost identical problem recently. I have rewritten my persistence
mechanism
> so that the concrete implementation is loaded at runtime after the backend
> database type has been determined.

> What I found I had to do was put my abstract persistence classes in one
> package and each set of concrete persistence classes in another. Then I
> built the projects using packages and specifying the abstract package in
the
> package list. You can limit the package list to that one only if you don't
> want to distribute all the Borland runtime packages.

> When the application runs, it loads the required concrete persistence
> classes package using 'LoadPackage'.

Franz-Leo Choms

Delphi Developer
Tue, 17 Feb 2004 05:22:24 GMT

Re:DLL or Packages: Shared Classes? HELP!


On Thu, 30 Aug 2001 15:39:48 -0500, "Richard Carruthers"

Quote
<carruthersr@H_otmail.com> wrote:
>I am writing a test app to try this now, however... I Still dont see how
>using packages will elliminate having 2 coppies of the class since the unit
>will be used in the exe and in the package - Do packages link to the main
>EXE's class table?

No. But the code which creates the instance is in an package which is
both used by the Application and your plugin package.

Regards from Germany

Franz-Leo

Bj?rge S?the

Delphi Developer
Tue, 17 Feb 2004 06:08:54 GMT

Re:DLL or Packages: Shared Classes? HELP!


"Richard Carruthers" <carruthersr@H_otmail.com> skrev i melding
news:3b8e9269$1_2@dnews...

Quote
> I have an app that I need to be modular, in that it needs to support
> multiple DataEngine Objects. Each DataEngine is responcible for maintaining
> a common interface (or course), but implement entirely different behavior.
I
> had the whole thing setup and working (I thought) until I hit this snag:

> Main EXE uses Unit A, and GenericDataEngine Unit;

> DLL creates a Descendant Class of GenericDataEngine, thus GenericDataEngine
> Unit is included in the DLL uses clause.
> DLL also needs to understand types (objects) from Unit A (as method
> parameters), so it also includes Unit A in its uses clause.

> Now this DLL procedure fails, even if OBJ is UnitAType:

> Function IsParamMyObj(Obj:TObject):Boolean;
> begin
>   Result :=(Obj is UnitAType);
> end;

> I believe this is because the DLL and the App have different class
> tables.... How can I merge them? Will using packages help? I don't just
need
> one or two classes, I need all the classes to be the same because I cannot
> tell what classes the DLL may use.

> Anyone have any Ideas... I'm pretty desperate here - my entire OO design
> hangs in the balance here.

Another way of solving this is using Interfaces, and redesign to get rid of
the "If Object is Type" - statements. Your driver-concept seems ideal for
Interfaces, as writing a class hierarchy for all databases may be a slight
overkill. This is *so* clean, as the only common code needed is the interface
daclaration. It doesn't even matter if one dll is compiled with another
Delphi version...even in another language, if you stick to the COM datatypes
and calling conventions.

--
Bj?rge S?ther
Konsulent & Utvikler
bjo...@itte.no
Kontor: Str?ket 41, 1383 ASKER
Post: Drengsrudveien 44, 1385 ASKER
Telefon +47 66 75 86 00
Fax +47 66 75 86 01
Mobil +47 90 82 22 39
Privat +47 66 90 38 61

Terry Fiel

Delphi Developer
Tue, 17 Feb 2004 09:53:59 GMT

Re:DLL or Packages: Shared Classes? HELP!


Quote
"Richard Carruthers" <carruthersr@H_otmail.com> wrote in message

news:3b8eab9d$1_2@dnews...

Quote
> can you give me a generic example of this..

> what I am looking for is a description of the process - such as:

> 1. Put Class A in Unit A
> 2. Use Unit A in Package A (Class holder package)
> 3. Use Unit A in MainApp.DPR (main exe)
> 4. Load Package A from with Package B (engine)
> 5. (MainApp.VarofClassA is Package B.VarofClassA) = true

Let's say we have an abstract persistence broker class called TplBroker. We
also have a concrete instance of that class that implements ADO
functionality called TplAdoBroker. The application logic is in a unit called
Unit1. The location of these components are as follows:

    Unit1 in main exe (uses plBroker)
    TplBroker in plBroker.pas in Package1 (doesn't refer to any outside
units)
    TplAdoBroker in plAdoBroker.pas in Package2 (uses plBroker)

I build the exe with 'use packages' ticked and Package1 in the package list.
Package2 is not loaded until I call LoadPackage.

Note that plAdoBroker has in initialization section which registers the
TplAdoBroker class which allows me to find the class using 'FindClass'.

Other Threads

1. OOP-Plugins: sharing class definitions and objects betrween exe and dll

2. Creating class instances in DLL shared memory

3. BCB4E: Class Explorer shows classes in package only once

4. Help for share variables between Application and DLL

5. .DLL ou .DCU (Package) - Please help me!!!!

6. .DLL ou .DCU (Package) - Please help me!!!!

7. HELP....Build With Runtime Packages....multiple dll project

8. Classes in DLLs - Help (Retry)

9. Classes in DLL's - Help

10. HELP: Class not Found error in ActiveX DLL