On Friday, 19 December 2014 at 01:59:05 UTC, Ellery Newcomer
wrote:
On 12/18/2014 12:41 PM, Laeeth Isharc wrote:
I have a bunch of D functions I would like to make available
to Excel
(and possibly Julia) without having to write wrappers for each
function
individually.
I've thought about refactoring the reflection parts of pyd into
a reusable library for e.g. resurrecting RuD. Come to think of
it, that would probably be necessary for supporting pypy.
It'd be a heck of a lot of work, though.
For your wrapper, you can probably do something like
extern(Windows) double vbwrap_test(double* inp,size_t
num_inp,double* oup,size_t num_oup)
{
return test(inp[0 .. num_inp], arg_oup[0 .. num_oup]);
}
with .dup sprinkled in as you see fit. And you don't need to
explicitly copy the results back! Might need to take the ref
off oup in test..
Thanks for the pointers, Ellery.
What was RuD? RubyD?
There may be more efficient purer ways of doing this, but I
don't wish to spend time learning Excel internals/object
models, and I know my route will work reasonably well).
ActiveX is not internal to Excel. Being a generic component
interface, it's available over almost all microsoft technologies.
True, but how does that help me right a function I can call from
a spreadsheet? I had understood ActiveX was for scripting the
app, but not so useful if you want to write a function that can
be entered in a cell formula. So it seems to me that ActiveX
doesn't create an obvious way to avoid writing a C API wrapper
and then VBA wrapper around that.
