>Ed Rauh,
> Hi, remember me?
> I have a problem when read the value from port Inp(PortAddress).
> In vb that is ok but in Vfp the return value is not same !
>
>VB code :
>>Dim value as integer
>>dim PortAddress as integer
>>value=0
>>Port Address= &H2Eo
>>'Write to a port.
>>Out PortAddress, Value
>>'Read back and display the result.
>>Text1.Text = Inp(PortAddress)
>
>In the text box it display the value of 1
>
>In VFP
>>Public nData
>>Public PortAddress
>>nData=1
>>PortAddress=0x2E0
>>*Write to a port.
>>Out(PortAddress, nData)
>>*Read back and display the result.
>>thisform.text1.value=Inp(PortAddress)
>
>In the text box it display 13041665 and convert to Hexadecimal is C70001.
>Sometime it also will display 13369344 convert to hexadecimal is CC0001.
>What's wrong ? Actually the correct result is 1

I don't know the .DLL involved, but it looks like it might be returning a SHORT (16 bit) rather than an INTEGER (32 bit) type value. Try changing the declaration for the Inp function to have a return value of SHORT rather than INTEGER. Alternatively, you can use the BITAND() function to mask the return value; BITAND(Inp(PortAddress),0xFFFF) would mask out the high-order bits to create a 16 bit return, or BITAND(Inp(PortAddress),0xFF) would mask it to only consider the low-order byte, for 8 bit return values.

It would be best to declare the .DLL entrypoint correctly.

>The DLL i declare is 32bit , is it VFP is 32bit Application ?

Yes, Visual FoxPro runs in 32 bit protected mode. The type of operating environment has nothing to do with the data types passed to and returned from a function; you have to get the return type and parameters for the .DLL declaration correct or things just won't work as you expect. Since I didn't write the .DLL and don't have the documentation for it, I'm guessing at the correct definition. IOW, RTFM.

You might try contacting the people who created the .DLL to find out the exact details of how the .DLL entrypoint behaves.

>thanks
>
>regards
>chang