🚀 go-pugleaf

to the message above...

bpl_1
//----------------------------------------------
   calls method located in bpl_2
//----------------------------------------------

bpl_2
//--------------------------------------------------------------------------
------------
TMyDataSet *a_MyDataSet = dynamic_cast<TMyDataSet *>(DataSource->DataSet);
this gives a NULL.
//--------------------------------------------------------------------------
--------------

But if i cast
TMyBaseDataSet *a_TMyBaseDataSet = dynamic_cast<TMyBaseDataSet
*>(DataSource->DataSet);
it works OK.

TMyBaseDataSet and TMyDataSet
implemented in the  bpl_2

The RegisterClass in both bpl does not give an effect. It works the same
way.
the main executable compiled with runtime packages.



Dmitry

"Dmitry" <dmitry@pikalevo.com> wrote in message
news:45c1f643@newsgroups.borland.com...

> I've move some working code from exe to bpl, and now
> dynamic_cast does not work in bpl.

Yes, it does.  Just not the way you think it does.

> meaning it always return NULL
> what can be a problem

You are not taking into account that the RTTI inside a package is
different than the RTTI inside the application or other packages.  You
can't allocate an object in a package, pass it to the application (or
another package), and then test the type of the object using a type
that is declared in a different module.  In order for dynamic_cast to
work, it has to be called in the same module that declares and
allocates the object type being tested.


Gambit

Remy,
>In order for dynamic_cast to
> work, it has to be called in the same module that declares and
> allocates the object type being tested.

maybe someone will give me idea how can i overcome this problem.

i have TDataSetActions and TMyDataSet  implemented in one package.(package1)

the other modules use this package for design purpose.
meaning, i develop forms with my TDataSetActions and TMyDataSet

the TDataSetActions use TMyDataSet descendant inside package1,
when user fires event for dataset, i need to cast a DataSet to TMyDataSet

TMyDataSet *a_MyDataSet = dynamic_cast<TMyDataSet *>(DataSource->DataSet)

and it this gives a NULL.
thus DataSet->ClassName() ==  "TMyDataSet"


some ideas will be appreciated.
please help.



Dmitry

"Dmitry" <dmitry@pikalevo.com> wrote in message
news:45c4f2a7@newsgroups.borland.com...

> maybe someone will give me idea how can i overcome this problem.

The only way for RTTI to work across packages is to enable runtime
packages.  It does not sound like you are doing that.

> the TDataSetActions use TMyDataSet descendant inside package1,
> when user fires event for dataset, i need to cast a DataSet to
TMyDataSet
>
> TMyDataSet *a_MyDataSet = dynamic_cast<TMyDataSet
*>(DataSource->DataSet)
>
> and it this gives a NULL.

If you know for a fact that the DataSet is always a TMyDataSet, then
you should be using static_cast instead of dynamic_cast.  The only
time you should ever use dynamic_cast is when you are not sure what
the actual type is going to be.


Gambit

Can you post an *exact* sc
"Dmitry" <dmitry@pikalevo.com> wrote in message 
news:45c1f643@newsgroups.borland.com...
> Hello,
>
> I've stuck with the problem.
> I've move some working code from exe to bpl, and now
> dynamic_cast does not work in bpl.
> meaning it always return NULL
> what can be a problem
>
> Dmitry
>
> 

*sigh* Fat fingered another post.  Let's try this again.

Can you post the *exact* setup you are using.  The number of packages you 
are using and *all* of your code.  Note, try to create a minimal scenario as 
it will make diagnosing the problem easier.

I use the package system heavily in my applications.  My apps are designed 
to run both with and without runtime packages.  When I am debugging my EXEs 
they are compiled "with runtime packages" to decrease compilation times. 
When I release they are built standalone.  Where it is required I use 
dynamic_cast in packages and EXEs without encountering the RTTI problems 
mentioned here.  The problem you are experiencing usually happens with raw 
DLLs or BPLs that have been loaded using LoadLibrary().

- Clayton

Dear Clayton,

>  The problem you are experiencing usually happens with raw
> DLLs or BPLs that have been loaded using LoadLibrary().

you are exact!
i use LoadLibrary to load my plugins.
The core bpl, which is loaded as runtime package,
loads my plugins by LoadLibrary.
Then  action in my plugin calls method in core bpl

bool __fastcall TFDataSetInsert::Execute()
{
    TDictDataSet *a_DataSet = dynamic_cast<TDictDataSet
*>(DataSource->DataSet);
    if(!a_DataSet) throw Exception("DataSet should be of type
TDictDataSet!");
}

please tell where can i upload test example of my problem.

thanks in advance,
Dmitry.

You can try using LoadPackage() rather than LoadLibrary() to load your 
plug-ins (if they are BPLs and not DLLs).  If the EXE and all of your BPLs 
are built with runtime packages then there might be a chance that the VCL 
will fixup the RTTI mapping.  However, I have no personal experience with 
this approach and won't be able to test until later in the day today.

> please tell where can i upload test example of my problem.

I think all of the information I need to have you provided in this last 
post.  It wasn't clear to me that you were creating plug-ins.  From your 
first post it appeared that you were simply breaking apart your program into 
packages.

- Clayton

Clayton

> I think all of the information I need to have you provided in this last
> post.  It wasn't clear to me that you were creating plug-ins.  From your
> first post it appeared that you were simply breaking apart your program
into
> packages.

In my design:
exe
  |
base.bpl ->loads plugin.bpl

But plugin.bpl contains components inplemented in base.bpl.(TActions)

The strange thing is that when i created example programm i got everything
working!

Looking for this bug still.
I will check out that plugin packages use runtime packages,
but i was sure that package uses runtime packages by nature.
Just don't know how to check.

Thank you for the help anyway.
Dmitry

Clayton,

> I think all of the information I need to have you provided in this last
> post.  It wasn't clear to me that you were creating plug-ins.  From your
> first post it appeared that you were simply breaking apart your program
into
> packages.

I have been striving with the problem for a 2 weeks already.
Today my dynamic_cast started to work when i inserted a line
to make sure that class name is the calss name i expect

AnsiString a_ClassName = DataSource->DataSet->ClassName();
TDictDataSet *a_DataSet = dynamic_cast<TDictDataSet *>(DataSource->DataSet);

after inserting:
AnsiString a_ClassName = DataSource->DataSet->ClassName();

my dynamic_cast in package started to work.
I even have no idea what is going on.


Dmitry

> Clayton,

in documentation for  TObject::ClassNameIs
i finding the next:
//--------------------------
Use ClassNameIs when writing conditional code based on an object's type or
to query objects across modules or DLLs.
//--------------------------

this gives me idea that my problem is known borland problem.
Meaning - always to use ClassNameIs of VCL but not dynamic_cast of C++.


I was not able to find key to the problem for 2 weeks already.
When i prepared simple example of dynamic_cast in packages - everything
worked
fine. But since i started to complicate the example up to existing model -
the glutch
appeared again.This glutch hardly dependent of length of module and even
name of class of my actions.
Since i change class name of my actions to something different it stopped to
work again!

SO dynamic cast worked only with
AnsiString a_ClassName = DataSource->DataSet->ClassName();
before it

and certain rule for class name. Eg. it worked for TMyDataSetAction
but did not for TDVKDataSetAction.

When i unremarked all the rest module code(which had no relation to
dynamic_cast at all)
dynamic_cast stopped to work again! So this also dependent of module length.

Please some ideas.

Dmitry

Have you tried using LoadPackage() and UnloadPackage() rather than 
LoadLibrary() and FreeLibrary()?

As is with your case I cannot create a small test case to duplicate your 
error.  My small tests work with both LoadPackage() and LoadLibrary().  If 
changing your load function doesn't help then perhaps you should zip up your 
files (minus the binaries like EXE, OBJ, LIB, BPL) and post a message to 
"borland.public.attachments".  I'll take a look at it.

- Clayton

Clayton

> Have you tried using LoadPackage() and UnloadPackage() rather than
> LoadLibrary() and FreeLibrary()?

yes. with thesame result.

> and post a message to
> "borland.public.attachments".  I'll take a look at it.

thanks in advance.
it may take a bit of time, preparing my packages to easy install by you.
they use kbmMemTable.

do you have them?

Dmitry

Dear Clayton,
please leave me your coordinates , it may take a time to prepare
example project of my problem, cos code is quite dependent.
dmitry at pikalevo com

>> Have you tried using LoadPackage() and UnloadPackage() rather than
>> LoadLibrary() and FreeLibrary()?
>
> yes. with thesame result.

Hi,
I once created a plugin system in our company with BCB5 and had the same  
issue in the very beginning.
The way to solve it was to ensure that all parts of the program (plugin,  
host, base bpl/dll) are compiled with dynamic RTL and VCL otherwise you  
end up with different instances of the VCL as already described by Remy.

To accomplish dynamic linking it might be useful to check your sources for  
'#pragma link' entries which should be removed.
Additionally you should check in all project files that the LIBRARIES  
section is empty, the SPARELIBS section should contain the same entries as  
found in the PACKAGES section (except the different extension of course)

HTH
Torsten

I was planning on simply looking at the structure of your code rather than 
attempting to recompile your code.  I wanted to see if something obvious 
stuck out.  However, if someone else that wants to help has the libraries 
you use then they would be able to compile your code.  Just zip what you 
have and put it in the attachments newsgroup and I'll get to it as soon as I 
can.

- Clayton 

Torsten,

> Additionally you should check in all project files that the LIBRARIES
> section is empty,
> the SPARELIBS section should contain the same entries as
> found in the PACKAGES section (except the different extension of course)

Why SPARELIBS should contain the same entries as PACKAGES?
I use to clear up  LIBRARIES and SPARELIBS completely for packages which
i don't expect to be used as statically linked.

BCB ofrouce want to put there something own each time.Lol.

Dmitry

Clayton,
> Just zip what you
> have and put it in the attachments newsgroup and I'll get to it as soon as
I
> can.

i will.

Dmitry

> Why SPARELIBS should contain the same entries as PACKAGES?

When building with runtime packages the IDE will look through this list and 
cross check it with the PACKAGES list.  The libraries that don't have a 
partner in the PACKAGES list are added to the LIBRARIES list.  I use this 
feature all the time when changing my projects back and forth between 
standalone and package-based.  However, I don't know if the filename is used 
to determine a match or if the contents of the libraries are checked.  I 
just know that it works.

> BCB ofrouce want to put there something own each time.Lol.

Yes, the IDE will commonly inject VCL.LIB and RTL.LIB into the SPARELIBS 
list.

- Clayton

Clayton

> When building with runtime packages the IDE will look through this list
and
> cross check it with the PACKAGES list.  The libraries that don't have a
> partner in the PACKAGES list are added to the LIBRARIES list.

not clear weather you mean <LIBRARIES> or <SPARELIBS>?

the hell is that in most cases BCB will compile package statically
if he does not find it in <PACKAGES> section and we will know nothing
about this up to time when problem appears.

for this reason, to make sure that i use ONLY RUNTIME PACKAGES model
i clear up the <SPARELIBS> section at all.
and <LIBRARIES> also.

But BCB is weird thing. It will put there(<SPARELIBS>) something each time.

the meaning of <SPARELIBS> is not clear for me anyway.
it complicate things.

Dmitry.