| Re: Call_External error in Virtual Machine [message #55143 is a reply to message #55140] |
Sun, 05 August 2007 17:17  |
bsoher
Messages: 5 Registered: May 2006
|
Junior Member |
|
|
Found my problem with some help from others ... so I'm replying to my
own email.
Turns out my problem is due to a difference between IDL 6.1 and 6.3.
I call C++ code using CALL_EXTERNAL, and I use the idl32.dll call,
IDL_StrStore(), to write error messages back to my IDL routine. In
IDL 6.3 (or maybe 6.2) they renamed this DLL to idl.dll which sort of
leaves me hanging out in the wind a bit.
RSI/ITT's (polite but not completely helpful) response to all this was
that CALL_EXTERNAL was meant to link in standalone C/C++ routines that
did not make use of IDL functionality. So, I can either create IDL
version specific releases for my program OR find a way to ditch
IDL_StrString(), which is the only function I call out of idl32.dll.
I figure that I'll set up my strings in the C++ call as fixed length
byte arrays and then use strncpy() to copy in any error messages. I
can then use the STRING() function in IDL to recreate these messages
for display.
Brian.
On Aug 2, 3:04 pm, bsoher <brian.so...@duke.edu> wrote:
> Hi,
>
> I have a windows DLL that I call from an IDL gui using the
> CALL_EXTERNAL mechanism that works just fine when I compile the
> application in IDL 6.1 and run it from the IDL command line. When I
> save the app (SAVE, /ROUTINES, /XDR, FILENAME=fname) and drop the
> fname.sav file onto the IDL 6.3 Virtual Machine shortcut, the
> application's gui pops up OK, but I get an error message from
> Call_External the first time it tries to access the DLL.
>
> The error index = -378
> The error msg = CALL_EXTERNAL: Error loading sharable executable.
> Symbol: gava_mysql_do_query, File=C:\WINDOWS
> \system32\libgava_main.dll
> The specified module could not be found.
>
> Again, this CALL_EXTERNAL call works just fine outside the VM. I've
> tried hardcoding the directory where the DLL is located (usually I
> just list the DLL name because system32 is in the search path) but
> this did not help.
>
> Any thoughts would be appreciated.
>
> Thanks,
>
> Brian.
|
|
|
|