Well, it is quite simple and I did explain it before but let me try again. We have an instrument connected to the host PC. The software running on the PC needs to read EEPROM data held in the instrument. It sends a command to the instrument and the instrument responds by the sending the data. The software uses the FTDI DXXX library to read and write to the USB. The data is read byte by byte. The FTDI routine returns the data as a string. The software uses the Asc() function to get the value of each byte. It all works fine except in Win10 running the chinese version.

Well, the code could not be simpler. Just one line of code. The rest is done by the FTDI library routine that reads the USB data and passes it as a string. It all works fine in all systems we tested except Win10 running the chinese version. But thank you for taking the time to comment.

Yes, the reason is that I am using the FTDI DXXX library to read data from the USB chip. This passes the data as a string.

AscB no good either. Thanks.

Thanks Homer. I tried AscW(string) but I still get the same error. For example: instead of reading 0 22 129 0 22 in the chinese PC I get 63 63 63 0 0 I also tried changing the regional settings in the PC to English but that did not work either.

Thanks for your reply. The code reads data (not text) from eeprom in the instrument. The FTDI driver (which I have no control over) returns each byte read from the USB bus as a string character. That is why I use Asc(string) to get me the byte value that I need. The problem, for example: instead of reading 0 22 129 0 22 in the chinese PC I get 63 63 63 0 0 Thanks again

Hello I am working with a piece of VB6 code that reads data from an instrument through the USB port. The instrument uses an FTID USB chip and the data is read by the host byte by byte from the USB bus using a driver supplied by FTID. Each data byte is returned as a string character and then converted using the function Asc(string). The problem is that on Windows 10 machines running chinese, the data returned is corrupted. I think this may have something to do with the longer (2 bytes per character instead of one) character coding used for chinese but I have not been able to understand the issue. Any suggestions?