Using LONGS with ActiveX Controls in VFP

[Paul H. Dunham]

I am using VFP V5.0. I have a 3rd party ActiveX control that takes a
32-bit integer as a parameter. When I try to call this function I get
"type mismatch" error. Does anyone know how to convert a NUMERIC to a
32-bit interger that can be passed into OLE/ActiceX's?

Thanks
Paul Dunham
Paul....@paritysoftware.com

[Gary Foster]

Here is one way to do it.

Gary Foster
Pointsource Consulting Inc

*-- This takes either an integer, e.g., 100 or a string, e.g., chr(100) +
chr(0) + chr(0) + chr(0)
*-- and converts it into the other type

LPARAMETERS tuIn, tnLength

LOCAL nIntegerLen
LOCAL nSignNum
LOCAL uSignedInteger
LOCAL cRawString
LOCAL nInc

DO CASE
CASE TYPE("tuIn") = "C"
nIntegerLen = LEN(tuIn)

IF ASC(SUBST(tuIn,LEN(tuIn),1)) >= 128
nSignNum = 256^LEN(tuIn)
ELSE
nSignNum = 0
ENDIF

uSignedInteger = 0
FOR nInc = 1 TO LEN(tuIn)
uSignedInteger = uSignedInteger + ASC(SUBST(tuIn,nInc,1)) *
256^(nInc-1)
ENDFOR

uSignedInteger = uSignedInteger - nSignNum

CASE TYPE("tuIn") = "N"
*-- If we want to explictly produce a four byte string, pass a 4 in
tnLength.
*-- If the passed number is too large or too small to be represented
in two bytes,
*-- automatically bump the byte length to 4.

IF (!empty(tnLength) AND tnLength = 4) OR
!BETWEEN(tuIn,-(256^2/2),256^2/2-1)
nIntegerLen = 4
ELSE
nIntegerLen = 2
ENDIF

*-- Use VFP's built-in function.
cRawString = BINTOC(tuIn,nIntegerLen)
uSignedInteger = ""

*-- Fix the goofy results that VFP's built-in function gives by
backing through
*-- the byte stream.
FOR nInc = nIntegerLen TO 1 STEP -1

*-- Left most byte is the high order byte according to bintoc().
IF nInc = 1
nLastByte = ASC(SUBSTR(cRawString,nInc,1))

IF tuIn < 0
nAdjuster = +128
ELSE
nAdjuster = -128
ENDIF

uSignedInteger = uSignedInteger + CHR(nLastByte + nAdjuster)

ELSE
uSignedInteger = uSignedInteger + SUBST(cRawString,nInc,1)
ENDIF
ENDFOR

ENDCASE

RETURN uSignedInteger

[Paul H. Dunham]

I tried this and I get the same problem. "OLE error code 0x80020005:
Type mismatch." I have not seen any evidence that FoxPro has the ability
to generate a true long integer type and pass it to OLE. Thank for the
suggestion though. -Paul

[James Grapes]

Dear Paul,
I have encountered a similar problem with a 3rd party DLL. The solution
was simply to do nothing special, except in either the way i passed the
variable or the way i declared it. For example the C calling structure for
the DLL was myCall(int,int,long)
declare integer myCall in myapi.dll integer,integer,integer
myCall(1,2,3)
that was it. Some of the calls required that i declare with the integer@
and some required that the parameter be passed with @param. The way I
looked at was 3 = 3 no matter how many bits the word has. The only
difficulty that I experienced was retreiving the longs back from a
structure that i had passed. I had to work a little for that.

Hope this helps.

James Grapes
j...@hardynet.com

----------
> From: Paul H. Dunham <phdu...@hooked.net>
> Newsgroups: microsoft.public.fox.programmer.exchange
> Subject: Re: Using LONGS with ActiveX Controls in VFP
> Date: Monday, November 02, 1998 2:34 PM

>
> I tried this and I get the same problem. "OLE error code 0x80020005:
> Type mismatch." I have not seen any evidence that FoxPro has the ability
> to generate a true long integer type and pass it to OLE. Thank for the
> suggestion though. -Paul
>
> Gary Foster wrote:
> >
> > >I am using VFP V5.0. I have a 3rd party ActiveX control that takes a
> > >32-bit integer as a parameter. When I try to call this function I get
> > >"type mismatch" error. Does anyone know how to convert a NUMERIC to a
> > >32-bit interger that can be passed into OLE/ActiceX's?
> > >
> > >Thanks
> > >Paul Dunham
> > >Paul....@paritysoftware.com
> >

Paul H. Dunham <phdu...@hooked.net> wrote in article
<363CBAD9...@hooked.net>...

[Donald Orphanidys]

James:

You raise a good point. I write DLLS in Delphi that I use in my VFP apps.
I hadn't had a problem until I wanted to return a string from the Delphi DLL
to VFP. A string is a string, yes? One would think so. _not_ A string
char in VFP passed to Delphi ain't the same thing.

I know that some of the advanced gurus out there will snicker at me but, I
learn something new every day. So...

I found that if the DLL has to manipulate or return a value, you must create
that value first and pass a pointer or reference to it and then have VFP
read the same memory space.

I had a simple SHBrowseForFolder DLL that was to pass back the chosen folder
or empty string to VFP. The DLL's input was a string; curdir(). I got the
input okay, but the DLL never returned anything. When I initialized mem
space for the return value and passed that by reference, badahbing
badahboom.

As in:
SpaceForReturn = space(255)
DLLFunction('DefaultParChar', @SpaceForReturn)
? SpaceForReturn

In Delphi, the string can be Char or PChar but VFP doesn't care. As long as
the data at the mem space was 'type-castable' in Delphi, it could manipulate
it and VFP could read it. I would think that a numeric could work with a
long or longint the same way.

Does this make sense?

--
Donald
mro...@sprynet.com
~~~~~~~~~~~~~~~
"For every complicated problem there is a simple and elegant solution-
--and it is wrong." -- H. L. Mencken

James Grapes wrote in message <01be09ca$9774a380$3617...@jrg.cfw.com>...