Delphi Object in DLL - does this work?
Alexander Halser
caller application that invokes the DLL. As far as I know, it doesn't work
to return just the object handle and use the object in the caller
application.
So I went on to save my object to a TMemoryStream in the DLL and return the
handle of the memory stream to the caller application. The caller
application gets the handle, assigns it to another TMemoryStream and
recreates the original object by reading the stream. Not very elegant, but a
nice workaround...
THIS DOES WORK! But is it reliable? I wonder whether it works because the
Delphi memory manager is installed on the development machine or if this
will work reliably on other computers, too. Is the memory stream a
consistent allocation of bytes or could it be broken?
--
Alexander Halser
johnnie
AS long as you use this DLL only from delphi programs this might
work as expected but this will not allow you to
use the DLL from other development environments (.NEt VB C++ etc).
Also the object code must exists in both the EXE and DLL which makes
me wander for the existanse of a DLL all together.
If you want this kind of support I would recomend to study
ActiveX/ole/COM/COM+ which is the technology used in windows
for this kind of things.
Regards
johnnie.
Peter Haas
Alexander Halser wrote in <3fa8e1e9$1...@newsgroups.borland.com>:
> I have got a Delphi object in a DLL which I want to make available to the
> caller application that invokes the DLL. As far as I know, it doesn't work
> to return just the object handle and use the object in the caller
> application.
>
> So I went on to save my object to a TMemoryStream in the DLL and return the
> handle of the memory stream to the caller application. The caller
> application gets the handle, ...
Do you mean the memory adress (TMemoryStream.Memory)?
Or do you mean the instance (variable)?
> ... assigns it to another TMemoryStream ...
Because you don't set the memory adress I guess, you use the instance.
> ... and recreates the original object by reading the stream. Not very
> elegant, but a nice workaround...
More a time bomb.
> THIS DOES WORK!
Possibly ostensibly.
> But is it reliable?
Not in any case. It need to have exact the same implementation of
TMemoryStream on both sides, application and DLL. This is not assured,
if you develop with different Delphi versions.
> I wonder whether it works because the Delphi memory manager is
> installed on the development machine or if this will work reliably on
> other computers, too.
In this case the memory manager don't have any effect, because read from
the TMemoryStream don't change memory allocation, which is make by the
DLL.
> Is the memory stream a consistent allocation of bytes or could it be
> broken?
The MemoryStream always use a consistent allocation.
Back to a better solution. A simple solution would be to use a package
instead of the DLL. On the other side, than increase the distributation
size and the restriction to the same Delphi version exists as well.
I think there are two other solutions, which do work with other Delphi
versions and possibly with other languages as well.
The first solution is to write a DLL interface, which contain all public
methods and properties as functions. Consider the instance as a handle
and use it as first parameter.
The other solution has johnnie describe in his posting, you can use a
interface to describe the class interface.
Bye Peter.
--
JEDI+ API, the active JEDI Header Conversions Project:
http://jediplus.pjh2.de
Alexander Halser
The DLL is used because it implements system hooks that are possible in a
DLL only. Both - the application and the DLL - are compiled with the same
Delphi version and it is assured that my custom object and the TMemoryStream
class are both of the same date/version. So is it save to use the Memory
Stream class ? If not, I could use the memory pointer directly, that's not
much effort.
Alexander
"Peter Haas" <newsgrou...@pjh2.de> wrote
> Alexander Halser wrote in <3fa8e1e9$1...@newsgroups.borland.com>:
Peter Haas
Alexander Halser wrote in <3fa959e9$1...@newsgroups.borland.com>:
> Both - the application and the DLL - are compiled with the same Delphi
> version and it is assured that my custom object and the TMemoryStream
> class are both of the same date/version. So is it save to use the
> Memory Stream class ?
In the currently Delphi versions and if you don't do any others, yes.
But this can be changed in later versions. E.g. the using of is or as
failed, any memory allocations can cause access violations.
> If not, I could use the memory pointer directly, that's not much
> effort.
This is always a better solution.
type
TSpecialMemoryStream = class(TCustomMemoryStream)
public
constructor Create(Memory: Pointer; Size: Integer);
function Write(const Buffer; Count: Longint): Longint; override;
end;
constructor TSpecialMemoryStream.Create(Memory: Pointer; Size: Integer);
begin
SetPointer(Memory, Size);
end;
resourcestring
SSpecialMemoryStreamWriteError = 'write is not allowed';
function TSpecialMemoryStream.Write(const Buffer; Count: Longint):
Longint;
begin
raise Exception.Create(SBufferStreamWriteError);
end;
Alexander Halser
Nice idea! Thanks!
Alexander
Peter Haas
Alexander Halser wrote in <3fa8e1e9$1...@newsgroups.borland.com>:
> I have got a Delphi object in a DLL which I want to make available to the
> caller application that invokes the DLL.
Yesterday, I have found randomly a developer guide, one chapter explain
something about DLLs (174 kB):
http://safariexamples.informit.com/0672321157/Ebooks/D5DG/chapter9.pdf