Hello Folks!

In VB, the OCX method emits "xyz" binary data but using VFP it emits different one: "abc." Looking at the CREATEBINARY() docs it says:

Visual FoxPro character strings can contain binary data. However, an ActiveX control or automation object character string (OLE VT_BSTR type data) cannot contain binary data. An ActiveX control or automation object passes binary data to applications such as Visual FoxPro as an array of VT_UI1 type data.

Visual FoxPro automatically converts binary data passed from an ActiveX control or automation object as an array of VT_UI1 type data to a Visual FoxPro character string. Visual FoxPro internally marks this character string as binary data passed from an ActiveX control or automation object. When the character string is passed back to an ActiveX control or automation object, Visual FoxPro automatically converts the character string to an array of VT_UI1 type data the ActiveX control or automation object expects.

Use CREATEBINARY( ) to convert character type data created in Visual FoxPro to a binary type character string you can pass to an ActiveX control or automation object. The minimum number of characters to which CREATEBINARY( ) can be abbreviated is 7.

In my best capacity to understand the above statement, the data passed by the OLE OCX is no longer the RAW data expected. What we needed is the RAW data. Unfortunately, when we asked the OCX vendor about this matter, they said that they are not supporting VFP language but they added that since VFP is also an MS product, the OCX might run with the same expected functionality. Vague answer though.

I suspect that since the OCX was done in VB, it behaves native to VB. Meaning, it emits OLE VT_BSTR binary data which is the RAW data we needed. In VFP, the OCX emits VT_UI1 type data.

How do you interpret the above CREATEBINARY() doc?

>>>>We're using U.r.U finger scanner for our HRM systems with Payroll module. At first, we use VB with Pentacom's OCX control for interfacing with the finger scanner. If using Access MDB to handle the binary data emits by the scanner, there is no problem. With VFP table however, it can not handle the data (Memo field). This time, we tried VFP form with the same OCX control expecting it to work with DBF (Memo Binary or ordinary Memo) as field type but the data have different value. The CREATEBINARY() function does not help either.
>>>>
>>>>Is VFP capable of handling Binary Data? How do you handle Binary Data in VFP?
>>>>
>>>>Any help extended would be highly appreciated.
>>>In addition to DF's offer:
>>>Have you assured the data in the VFP memo is valid data?
>>
>>This is exactly my problem. Actually the OCX emits binary data. It is not a file.
>>
>>

>>cBinary = Thisform.OleOCX.GetFingerPrint()
>>Replace mydbffile.memofield With cBinary
>>

>>Above code successfully save the contents of the cBinary variable to a memo field (memo binary) but I don't know if it is a valid data.
>>

>>cBinaryCheck = Thisform.OleOCX.CheckFingerPrint(mydbffile.memofield)
>>

>>it always returns .T. even if the saved fingerprint was of my Thumb finger whereas scanned one was my index finger.
>>
>>>There maybe a GETCHUNK method available, check your control documentation.
>
>Jess,
>VFP can handle binary data and you can store any binary data to a memo (binary) - even an exe file as is. Even char binary fields can keep data as is (including chr(0)). An FTP file entry simply has a block header then the data as is. No conversion is done on memo side. That's OCX that cannot handle binary directly but convert to 8 bits byte array (BSTR to unsigned8bit char array - BstrToVector). CreateBinary() calls VectorToBstr to create back BSTR. If you could find a method in your OCX that would save w/o a conversion use it. See CreateBinary() help for details.
>PS: I would hate if it didn't return .T. thumb vs index finger. Track pattern is same:)
>Cetin