🚀 go-pugleaf

"Dmitry Konnov" <dmitry@weblinedesign.biz> wrote:

>I have set of methods and VCL classes in main executable of application,
>which I have to use inside bpl.
>
>In bpl code I declare methods implemented in main executable like this:
>
>extern "C"  TComponent * __declspec(dllimport) MyExeMethod();
>
>When I compiling bpl,  I get linker error
>Unresolved external MyExeMethod() refernced from ....

You can't do that. You can't export a function from the application and
import it into the DLL, because there's no export library produced by
the DLL.

You need to build your code up in layers. The bottom layer is DLLs that
don't require any other DLLs. Next up, you can have DLLs that only
require DLLs from lower layers. And so on up, until you get to the
application, which is where you stop - you can't have DLLs higher that
an app.

There look to be a couple of solutions:

a) pass pointers from the app to the DLL

b) pull the VCL classes out of your app and put them in the DLL.


Alan Bellingham
-- 
ACCU Conference: 11-14 April 2007 - Paramount Oxford Hotel

Alan Bellingham wrote:

> a) pass pointers from the app to the DLL

A couple of years ago we switched from exporting numerous functions
from the DLL to exporting four dispatcher functions using control
structures much like IOCTL.

Then we grouped the dispatchers into a single controlling structure
that took care of loading/unloading the DLL and made it easy to pass
them around between different libraries rather than have each library
reload the main DLL.

Then we wrote several useful classes based on the structure.

Now we've started using those classes in the DLL by having it populate
the group structure with its own functions. It works well except when
we have to explain to the non-coding management what we intend to do.
They keep asking where the functions actually are :)

-- 
Andrue Cope [TeamB]
[Bicester, Uk]
http://info.borland.com/newsgroups/guide.html

Andrue

Thank you very much. I will follow your advice
by separating common methods and classes into separate bpl
and using them withing exe and another bpl.

Dmitry.

"Dmitry Konnov" <dmitry@weblinedesign.biz> wrote in message
news:447171ab@newsgroups.borland.com...

> In bpl code I declare methods implemented in main executable like this:
>
> extern "C"  TComponent * __declspec(dllimport) MyExeMethod();
>
> When I compiling bpl,  I get linker error
> Unresolved external MyExeMethod() refernced from ....

You can't import functions from the application into the package like that.
You have two choices:

1) declare the functions as __declspec(export) in the application, and then
have the package obtain them via LoadLibrary() and GetProcAddress() at
runtime.  Even though it is not a DLL, an application executable can
actually be loaded via LoadLibrary(), and will have a suitable exports table
for GetProcAddress() to find.

2) have the package export a function that the application can call to pass
its function pointers to the package programmably.  This is the preferred
way to share functions from an application to a DLL.  For example:

    --- MyDll.h ---

    #ifndef MyDllH
    #define MyDllH

    #ifdef _BUILDING_DLL_
    #define MY_EXPORT __declspec(dllexport)
    #else
    #define MY_EXPORT __declspec(dllimport)
    #endif

    typedef TComponent* __fastcall (*MyExeMethod)();

    #pragma pack(push, 1)
    struct sMyFunctions
    {
        MyExeMethod Method1;
        //...
    };
    #pragma pack(pop)

    #ifdef __cplusplus
    extern "C" {
    #endif

    MY_EXPORT void __stdcall SetDllFunctions(sFunctions *pFuncs);

    #ifdef __cplusplus
    }
    #endif

    #endif


    --- MyDll.cpp ---

    #define _BUILDING_DLL_
    #include "MyDll.h"

    sMyFunctions Funcs = {0};

    void __stdcall SetDllFunctions(sFunctions *pFuncs)
    {
        if( pFuncs )
            memcpy(&Funcs, pFuncs, sizeof(Funcs));
        else
            memset(&Funcs, 0, sizeof(Funcs));
    }

    void DoSomething()
    {
        TComponent *pComp = NULL;

        if( Funcs.Method1 )
            pComp = Funcs.Method1();

        // use pComp as needed ...
    }

    --- MyApp.cpp ---

    #include "MyDll.h"

    TComponent* __fastcall MyMethod()
    {
        // do something ...
        return SomeObject;
    }

    __fastcall TForm1::TForm1(TComponent *Owner)
    {
        sMyFunctions funcs = {0};
        funcs.Method1 = &MyMethod;

        SetDllFunctions(&funcs);
    }

    __fastcall TForm1::~TForm1()
    {
        SetDllFunctions(NULL);
    }


Gambit

Remy

> 1) declare the functions as __declspec(export) in the application, and
then
> have the package obtain them via LoadLibrary() and GetProcAddress() at
> runtime.  Even though it is not a DLL, an application executable can
> actually be loaded via LoadLibrary(), and will have a suitable exports
table
> for GetProcAddress() to find.
>
> 2) have the package export a function that the application can call to
pass
> its function pointers to the package programmably.  This is the preferred
> way to share functions from an application to a DLL.  For example:

That is fine.
I did not know that LoadLibrary can be used for exe.

Is that possible to export VCL classes from out of exe to dll/bpl
by one of this method?

Dmitry

"Dmitry Konnov" <dmitry@weblinedesign.biz> wrote in message
news:4472ea32$1@newsgroups.borland.com...

> Is that possible to export VCL classes from out of exe to
> dll/bpl by one of this method?

I would not recommend that.  What EXACTLY are you trying to accomplish?


Gambit

Remy

> > Is that possible to export VCL classes from out of exe to
> > dll/bpl by one of this method?
>
> I would not recommend that.  What EXACTLY are you trying to accomplish?

I want to separate Application Core functionality(staff.bpl) and GUI
(forms.bpl).
For this I moved Application Core functionality to one bpl
and Forms GUI to another bpl.

I want each of bpl to be able use one another, but without
#include

to make then independant of compilation process.

Can you explain how to export VCL class to from one bpl to another without
#include

Dmitry

"Dmitry Konnov" <dmitry@weblinedesign.biz> wrote in message
news:447411f3$1@newsgroups.borland.com...

> I want each of bpl to be able use one another

You would have to include each package in each other's "Requires" list.  But
I don't know if the VCL allows circular references of packages.  Otherwise,
dynamically load the packages at runtime with the LoadPackage() function.

A better choice is to move the common logic into a third package, such as
common.bpl.  That way, staff.bpl and forms.bpl only contain their specific
logics, and they use common.bpl for the shared stuff.

> but without #include

You still have to use #include statements in order for each package to know
about the other's types.  Separating the logic into packages does not change
that.

> Can you explain how to export VCL class to from one bpl to
> another without #include

That is not how it works.


Gambit

Remy

> You would have to include each package in each other's "Requires" list.
But
> I don't know if the VCL allows circular references of packages.

Yes it allows and i got it compiled.
But when i deleted both bpi files i could not compile both bpls any more.

Dmitry