c++dlladoc++builder-6datamodule

Delete TDataModule but keep TADOConnection intact


I have a lib with some TDataModules who share a TADOConnection. I create and delete datamodules in some applications.

When I delete a datamodule, I get an EAccessViolation error. I think this is due to the fact that the datamodule wants to delete the TADOConnection, which is shared.

I tried setting the tdatamodule->tbquery->Connection property to NULL when the destructor is called, without any luck.

Why do I think the error resides in TADOConnection? Because when I build my application without a lib, I can create and delete datamodules without any problems. And when I create a lib with datamodules who have their own connection, I have no problems either.

Any help? Thanks in advance!

The error: http://oi60.tinypic.com/noyc6x.jpg

The call stack: http://oi61.tinypic.com/sgljx5.jpg


Solution

  • The solution is adding borlndmm.dll to the project folder of the application using the libraries or dll's.

    From the dll/lib projects in Borland C++ Builder:

    //---------------------------------------------------------------------------
    //   Important note about DLL memory management when your DLL uses the
    //   static version of the RunTime Library:
    //
    //   If your DLL exports any functions that pass String objects (or structs/
    //   classes containing nested Strings) as parameter or function results,
    //   you will need to add the library MEMMGR.LIB to both the DLL project and
    //   any other projects that use the DLL.  You will also need to use MEMMGR.LIB
    //   if any other projects which use the DLL will be performing new or delete
    //   operations on any non-TObject-derived classes which are exported from the
    //   DLL. Adding MEMMGR.LIB to your project will change the DLL and its calling
    //   EXE's to use the BORLNDMM.DLL as their memory manager.  In these cases,
    //   the file BORLNDMM.DLL should be deployed along with your DLL.
    //
    //   To avoid using BORLNDMM.DLL, pass string information using "char *" or
    //   ShortString parameters.
    //
    //   If your DLL uses the dynamic version of the RTL, you do not need to
    //   explicitly add MEMMGR.LIB as this will be done implicitly for you
    //---------------------------------------------------------------------------