Re: [DUG] Passing Objects to a DLL

[Phil Middlemiss]

Title: Message

Hi Matt, casting doesn't actually work when you are trying to compare class types since you don't know what class you have anyway. The tag idea may as well just be the the classname which is what we use as a workaround anyway. If an object is passed into a dll it's fine since it shares the same application space, but I think the issue is with the run time type information that Delphi uses. For example if I use the debugger to have a look at a class variable passed into a dll, it doesn't give the classname, it give something like TClass($4F801) (except a real memory address). Thanks anyway.   Cheers, Phil. ----- Original Message ----- From: Matt Comb To: NZ Borland Developers Group - Delphi List Sent: Wednesday, September 08, 2004 4:54 PM Subject: Re: [DUG] Passing Objects to a DLL Hey Phil, as you know doubt know, passing any type of memory around that is dynamic (e.g. string) as apposed to static (e.g. integer) is not a good idea. I haven't looked but maybe this class information uses strings to store different things, and therefore is unreliable.   How many different types of object are you passing through? could you perhaps set the object tag value (e.g. tag=1 = twhatever tag=2 = twhatever2 and then cast type within the dll? ) This would mean though that you would have to upgrade your dll if you want to support any additional type of objects.   By the way, I would recommend you not doing this at all. I would pass what information you need from the object through in a static object type, create an object of the type required within the dll and do what you have to do, but of course that would completely depend on the type of object you are throwing around.   Matt.   ----- Original Message ----- From: Phil Middlemiss To: NZ Borland Developers Group - Delphi List Sent: Wednesday, September 08, 2004 4:47 PM Subject: [DUG] Passing Objects to a DLL When an object is passed to a DLL it comes across fine and all properties and methods can be accessed, but somehow the class information gets handled differently. Using the "is" comparison fails when it should work - even InheritsFrom doesn't work. We've got around this in the past by using a recursive routine to compare class/ancestor names but I'm beginning to wonder if there is a trick that I have missed somewhere.   Can anyone shed any light on this?   Cheers, Phil. _______________________________________________ Delphi mailing list [EMAIL PROTECTED] http://ns3.123.co.nz/mailman/listinfo/delphi _______________________________________________ Delphi mailing list [EMAIL PROTECTED] http://ns3.123.co.nz/mailman/listinfo/delphi

_______________________________________________
Delphi mailing list
[EMAIL PROTECTED]
http://ns3.123.co.nz/mailman/listinfo/delphi