PerlCtrl, COM objects and callbacks

[axtens]

G'day everyone

I have a VB application (though it could easily be any other 3GL)
which calls a PerlCtrl'd COM object. What I'd like to be able to do is
to create a real (or ersatz) callback mechanism. The idea would be to
pass to the Perl object a long containing the address of a function or
procedure and have Perl call that address. IIRC, the COM object would
run in-process so the address would be meaningful within that
context.

I can generate the address and pass it in to the COM. What I don't
know is how to have Perl either call or jump to that address.

Any ideas? Should I give up now, before I do any damage?

Kind regards,
Bruce.

 

[Ben Morrow]

I have a VB application (though it could easily be any other 3GL)
which calls a PerlCtrl'd COM object. What I'd like to be able to do is
to create a real (or ersatz) callback mechanism. The idea would be to
pass to the Perl object a long containing the address of a function or
procedure and have Perl call that address. IIRC, the COM object would
run in-process so the address would be meaningful within that
context.

Better would be if you could pass some sort of COM object with a single
method Perl can invoke (the Java 'functor' pattern, commonly used in OO
languages as a poor substitute for closures). I've no idea how you might
do this from VB, but I would have thought it's possible.

I can generate the address and pass it in to the COM. What I don't
know is how to have Perl either call or jump to that address.

You can't call a function by machine address from Perl. If you have a
compiler you can write a tiny bit of XS to do this, trivially (assuming
you know the prototype/calling convention at compile time). If you
don't, but the called functions use the __stdcall calling convention
(likely if they're not C functions) then you ought to be able to fake up
a Win32::API object using the address given and then invoke that.

Any ideas? Should I give up now, before I do any damage?

Just be aware that poking about in memory like this undercuts the safety
of a high-level language like Perl or VB: you need to be as careful as
you would be in C or assembler. If you get segfaults or random memory
corruption, they're your fault .

Ben