#BAD DLL CALLING CONVENTI
6 messages in this thread
Jonathan,
I WAS trying to create a function that returned a double and got the
same results as our friend that started this thread. I tried your
suggestion (by only adding the param to the BC++ function) but crashed
with an "Exceeded segment bounds" error in Vis Basic Dr. Watson report. So
I tried it by creating a sub to get the double back to Vis Basic and it
worked as I documented in Friday's message – HOWEVER… after more
testing, I get inconsistent results with the SUB (it seems to randomly
crash after x number of calls to the double routine – and x can be
anything) with the Exceed segment bounds error.
I am going to try your original suggestion again and if I get anything
I'll get back to you.
There is 1 Reply.
TO,
I'll be interested to see your results. Let me see the code if it
doesn't work and I'll see if their is anything obvious. I need to file
BC++ back up and get a working demo done so that I can just "quote" it when
this issue comes up, as it often does. I am working on a column for the
upcoming WinTech Journal. I'll try to put something in print there. -=-
Jonathan
There is 1 Reply.
Jonathan,
No succes with the double function. What I'm trying to do is extract a
database numeric field (in character format) in my DLL, convert it to a
double, and pass that value back to Vis Basic when Vis Basic requests it by
supplying a field name.
Declared as:
Declare vxDouble (FieldName as String) As Double
Called with:
Amount# = vxDouble("amount_fld")
BC++ function:
double * FAR PASCAL vxDouble(char * fieldname, double * dval)
{
*dval = vxFldDouble(fieldname);
return dval;
}
Looks simple enough. I think wthis is what you were getting at. I have a
C test program that I use for debugging the DLL functions and it shows my
internal function vxFldDouble works fine. The Vis Basic SUB structure I
passed along the other day also works OK but I would like this to be a
function to lend some consistency to the DLL calling conventions.
The code sequence above stops the "BAD DLL CALLING CONVENTION" in Vis
Basic but results in a crash in the DLL. Dr. Watson reports a "Null
Selector (Read)" error and the ds register shows a null pointer.
Any other suggestions?
There is 1 Reply.
T.O. –
What memory model is BC++ using? VB is basically running in large
model and treats all data items as far by default. Make sure that BC++
understands "*" to mean a long (far) pointer and not a near pointer. In
addition, you should use "ByVal FieldName As String" in the VB Declare. VB
will pass 4-byte (long) pointers to the string and to the phantom variable
and expects the same long phantom pointer back as the function result.
— Jim
There is 1 Reply.
Jim
I'm using a large model to compile the DLL with and BC++ definitely
understands and defaults all pointers to FAR. I inadvertently omitted the
"Byval" keyword in my sample code but it was really there. I've even
explicitly cast the pointers as FAR with the same result. My C test program
calls the same functions and works perfectly.
There is 1 Reply.
T.O. –
Sorry, then… that was my only shot. I have no trouble writing
functions which return floating point values, and I follow the same rules.
Difference is I'm writing the DLL in MASM, not BC++. I can guarantee you
that the "model" you've been presented with here does work… it must be
something that BC++ is doing or not doing, because it definitely can be
done using MS products.
— Jim