Watch, Follow, &
Connect with Us

For forums, blogs and more please visit our
Developer Tools Community.


Welcome, Guest
Guest Settings
Help

Thread: TFrame inside a dll


This question is answered.


Permlink Replies: 4 - Last Post: Jun 23, 2015 11:55 PM Last Post By: Remy Lebeau (Te...
Ahmed Sayed

Posts: 173
Registered: 8/9/07
TFrame inside a dll  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 19, 2015 3:19 AM
Hello everyone,

I am trying to create custom TFrame decedents inside a dll but I am facing a major problem with TFont. I get the famous error “Cannot assign TFont to TFont”.

The dll is built without linking to run-time packages so as the calling app, I don’t want to use packages (BPL) instead of dll and I don’t want to link with run-time packages. Also note that I am using DevExpress controls and styles on both (Frames and App).

I have no idea how to fix this is? Is this a limitation in Delphi or just C++ builder?
Please someone help me in this if there is some kind of workaround or anything else.

Thanks in advance.

--
The limits of my language mean the limits of my world
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: TFrame inside a dll
Correct
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 20, 2015 10:42 PM   in response to: Ahmed Sayed in response to: Ahmed Sayed
Ahmed wrote:

I am trying to create custom TFrame decedents inside a dll but I am
facing a major problem with TFont. I get the famous error “Cannot
assign TFont to TFont”.

Your DLL and EXE are not linked with Runtime Packages enabled, so they are
not sharing a single copy of the RTL in memory, but instead have their own
individual copies. RTTI in the DLL's copy does not match with the RTTI of
the EXE's copy. The error occurs because a TFont object allocated inside
the EXE is being Assign()'ed to a TFont object allocated inside the DLL (or
vice versa), and internally the TFont::Assign() method (which takes a TPersistent*
as input) has to perform an RTTI lookup to make sure the input object is
actually a TFont before it can copy values from it. That RTTI lookup fails
without runtime packages enabled, thus the "cannot assign" error.

The dll is built without linking to run-time packages

That is why it fails. You MUST enable that option in both DLL and EXE when
using VCL/RTL objects across the DLL boundary.

I don’t want to use packages (BPL) instead of dll

Why? Packages are just DLLs with additional RTL/VCL support built in to
them.

I don’t want to link with run-time packages.

Sorry, but you must, if you want to share RTL/VCL objects across the DLL
boundary. Otherwise, you need to redesign your code/UI to remove that dependancy.

Also note that I am using DevExpress controls and styles on both (Frames
and App).

Irrelevent.

I have no idea how to fix this is?

Yes, you do, as you already stated the fix in your question (link to runtime
packages). You just don't want to use it the way it is meant to be used.

--
Remy Lebeau (TeamB)
Ahmed Sayed

Posts: 173
Registered: 8/9/07
Re: TFrame inside a dll  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 22, 2015 12:28 AM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
Thanks Remy,

I know that i need to link with run time packages for this to work but i was hoping to find another way to do it. Anyway the problem is that will force me to deploy a lot of BPL files with the .exe including DevExpress Bpl files to make the controls work now can't i just deploy the vcl.bpl and rtl.bpl and still make work?
--
The limits of my language mean the limits of my world
Bruce Salzman


Posts: 56
Registered: 8/23/02
Re: TFrame inside a dll
Helpful
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 22, 2015 12:06 PM   in response to: Ahmed Sayed in response to: Ahmed Sayed
Ahmed Sayed wrote:

Thanks Remy,

I know that i need to link with run time packages for this to work
but i was hoping to find another way to do it. Anyway the problem is
that will force me to deploy a lot of BPL files with the .exe
including DevExpress Bpl files to make the controls work now can't i
just deploy the vcl.bpl and rtl.bpl and still make work?

You can choose which runtimes to use. I only specify rtl, and link the
rest statically.

--
Bruce
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: TFrame inside a dll  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 23, 2015 11:55 PM   in response to: Ahmed Sayed in response to: Ahmed Sayed
Ahmed wrote:

I am trying to create custom TFrame decedents inside a dll but I am
facing a major problem with TFont. I get the famous error “Cannot
assign TFont to TFont”.

Your DLL and EXE are not linked with Runtime Packages enabled, so they are
not sharing a single copy of the RTL in memory, but instead have their own
individual copies. RTTI in the DLL's copy does not match with the RTTI of
the EXE's copy. The error occurs because a TFont object allocated inside
the EXE is being Assign()'ed to a TFont object allocated inside the DLL (or
vice versa), and internally the TFont::Assign() method (which takes a TPersistent*
as input) has to perform an RTTI lookup to make sure the input object is
actually a TFont before it can copy values from it. That RTTI lookup fails
without runtime packages enabled, thus the "cannot assign" error.

The dll is built without linking to run-time packages

That is why it fails. You MUST enable that option in both DLL and EXE when
using VCL/RTL objects across the DLL boundary.

I don’t want to use packages (BPL) instead of dll

Why? Packages are just DLLs with additional RTL/VCL support built in to
them.

I don’t want to link with run-time packages.

Sorry, but you must, if you want to share RTL/VCL objects across the DLL
boundary. Otherwise, you need to redesign your code/UI to remove that dependancy.

Also note that I am using DevExpress controls and styles on both (Frames
and App).

Irrelevent.

I have no idea how to fix this is?

Yes, you do, as you already stated the fix in your question (link to runtime
packages). You just don't want to use it the way it is meant to be used.

--
Remy Lebeau (TeamB)
Legend
Helpful Answer (5 pts)
Correct Answer (10 pts)

Server Response from: ETNAJIVE02