In the Delphi world there are 2 kinds of function pointers: there's the
"basic" function pointer you get when you ask for the address of a function
(using the @ operator) and there are "closures" (the kind of function
pointers used in Delphi's events). The basic function pointer only has one
address stored in it, the address of the function itself. The "closure" has
an extra pointer, an pointer to the object the function operates on.
If the DLL you're using requires the use of a basic function pointer there's
no easy way you can replace that with a "closure" pointer. The DLL would
have no idea what to do with the extra pointer. Also you can't use the code
you mentioned (ignoring the typecast error) because that would "extract" the
pointer to the actual code of the function, and if you'd call that you'd get
an AV because of the invalid "Self" parameter on the stack!
I can only think of 2 solutions for this problem:
1) Use a basic, global function that forwards the call to your object.
2) Dynamically generate code at runtime and use that as a DLL-friendly proxy
for your object. You'll need to know some basic assembly and I'm not sure if
this will work with XP SP2 as I know there's an option to prohibit
application from running stuff in the data segment.
----- Original Message -----
From: "Ross Levis" <[EMAIL PROTECTED]>
To: "Borland's Delphi Discussion List" <[email protected]>
Sent: Monday, July 04, 2005 4:58 AM
Subject: TMethod.Code
In a component I'm writing, I'm loading a DLL which needs to call a
function in my component. I've got this working with a global function
but I would rather the function be a method inside an object so I can
have access to my objects data when the call is made.
With some investigation, I thought I could do this:
DLLOpen := TMethod(Open).Code; <<< Invalid typecast
Open is a function defined in my object.
DLLOpen is the function pointer defined in the DLL which I assign to the
method code pointer.
I'm not sure why this doesn't work. I'm currently using global
variables with a global function, but I would much rather not.
Thanks,
Ross.
_______________________________________________
Delphi mailing list -> [email protected]
http://www.elists.org/mailman/listinfo/delphi
_______________________________________________
Delphi mailing list -> [email protected]
http://www.elists.org/mailman/listinfo/delphi
