Just as a side note.

The last time I developped a com interface in .net and used that object in
excel I had a hell of a lot of problems with versioning etc.

What I ended up doing, and it worked very well, was wrap the Com .net object
in a WSC windows script component. I don't know if they are stil usable in
windows 7, but they fixed no end of silly errors.  The bonus is you can
change the interface of the script object and it still retains the same
reference, making bug fixes a doddle.

Davy.


On Mon, Nov 29, 2010 at 12:29, Greg Keogh <g...@mira.net> wrote:

> I've replicated your problem with a simple VB6 class.
> I'm not sure of the actual cause but your fix is:
>    id = client.SendRequest((request))
> (cut)
>
> Mark, pardon my French, but holy shit! That works. Putting (()) around the
> object argument sends it and gives me a string reply, which previously gave
> me the runtime error.
>
> I'd been searching for hours and never found any such syntax or clues
> anywhere. Where did you get that trick?
>
> Now I'm passed that hurdle I've reached the next one ... I'm getting
> "Unable
> to find assembly xxxx", which I know is a lie. In this case I'm passing a
> string as an argument and getting back the same object that I'm passing in
> my previous problem. So now I can send it, but not get it back. Some sites
> hint at missing serializable attributes or incorrect COM attributes on the
> interface or classes, but that doesn't seem likely so far. Oh well, I'll
> keep slogging away and let you know if I find the answer.
>
>
> http://stackoverflow.com/questions/1733087/unable-to-call-c-code-from-vbscri
> pt-activex-error<http://stackoverflow.com/questions/1733087/unable-to-call-c-code-from-vbscri%0Apt-activex-error>
>
> Thanks heaps,
> Greg
>
>

Reply via email to