Asian and USA Compatibility Question

This code works on USA computers:

Code:

---

      Dim MyData As String, StartRead As Long, EndRead as Long
10    Open AppPath & "Stems" For Binary As #1
20    MyData = Space$(LOF(1))
30    Get #1, , MyData
40    Close #1
50    StartRead = InStr(MyData, "Hello")
60    EndRead = InStr(StartRead, MyData, ".")

---

It produces a "Runtime error 5" in line number 60 on Asian computers with the language set to Chinese, probably due to the double-byte characters that somehow get into MyData. StartRead is 0.

(1) How can I adjust the code so that it will work on both machines?

(2) How can I change the settings on my XP machine so that I can emulate the Chinese computers to help me debug this code?

Just a hunch, but you could try the chrW function...

Quote:

---

Originally Posted by HanneSThEGreaT

Just a hunch, but you could try the chrW function...

---

I'm also firing from the hip, but what about this possibility?

Code:

---

Dim MyData As String, StartRead As Long, EndRead as Long
10    Open AppPath & "Stems" For Binary As #1
20    MyData = Space$(LOF(1))
30    Get #1, , MyData
35    MyData = MidB$(MyData, 1)
40    Close #1
50    StartRead = InStr(MyData, "Hello")
60    EndRead = InStr(StartRead, MyData, ".")

---

Would statement 35 clean the string? It doesn't bother my USA (English) machine.

It should :)

Did you try it ¿

Quote:

---

Originally Posted by HanneSThEGreaT

It should :)

Did you try it ¿

---

I sent a repair version off to China for testing, but they are all asleep now--12-hour time difference. I cannot get my machine to produce the error 5, regardless of what I do (Question 2 in Post #1). I've imported the languages required from the XP disk and used My Computer to change the Language setting to Chinese (Singapore), but that will not allow me to reproduce the error 5 that they are getting. In short, they can test the code and I can't seem to do it.

Any thoughts on this?

Just a hunch. i could be wrong...

Try this on both pcs. What do you get?

vb Code:

StartRead = InStr(MyData, "Hello")
lenStartRead = Len(StartRead)
If lenStartRead <= 1 Then
    MsgBox "Hi"
End If

Quote:

---

Originally Posted by koolsid

Just a hunch. i could be wrong...

Try this on both pcs. What do you get?

vb Code:

StartRead = InStr(MyData, "Hello")
lenStartRead = Len(StartRead)
If lenStartRead <= 1 Then
    MsgBox "Hi"
End If

---

Kools, StartRead is dimensioned as a long integer. How can Len(StartRead) do anything but return 4?

Like I mentioned... just a hunch...Did you try it? What do you get at the time of error?

Quote:

---

Originally Posted by Code Doc

I sent a repair version off to China for testing, but they are all asleep now--12-hour time difference. I cannot get my machine to produce the error 5, regardless of what I do (Question 2 in Post #1). I've imported the languages required from the XP disk and used My Computer to change the Language setting to Chinese (Singapore), but that will not allow me to reproduce the error 5 that they are getting. In short, they can test the code and I can't seem to do it.

Any thoughts on this?

---

If you change your regional settings to Chinese (Singapore) and you don't get the error, then it appears, you have fixed it.

Quote:

---

Originally Posted by abhijit

If you change your regional settings to Chinese (Singapore) and you don't get the error, then it appears, you have fixed it.

---

I wish that were the case. I did not get the error using the code I posted in Post #1 after I changed my settings. They got error 5, meaning StartRead is 0 and "Hello" cannot be found. I also thought I had it fixed at that point. No such luck. :sick:

What test base are you using? Are you providing them a text file? If so, maybe you should ask them for the text file they are using, including the string returned from App.Path

Code:

---

Dim sPath As String, bData() As Byte
sPath = App.Path
ReDim bData(1 To LenB(sPath))
CopyMemory bData(1), ByVal StrPtr(sPath), UBound(bData)
Open "testdata.bin" For Binary As #1
Put #1, 1, bData()
Close #1

---

Maybe do similar for their Stems file?
After reviewing those files, you may gain more information?

See if anything on this site rings a bell.

Quote:

---

Originally Posted by LaVolpe

What test base are you using? Are you providing them a text file? If so, maybe you should ask them for the text file they are using, including the string returned from App.Path

Code:

---

Dim sPath As String, bData() As Byte
sPath = App.Path
ReDim bData(1 To LenB(sPath))
CopyMemory bData(1), ByVal StrPtr(sPath), UBound(bData)
Open "testdata.bin" For Binary As #1
Put #1, 1, bData()
Close #1

---

Maybe do similar for their Stems file?
After reviewing those files, you may gain more information?

See if anything on this site rings a bell.

---

Hi, Fox. I really need some help here. My code in post #3 using Mid$B() did not work, the same error 5 exists. They reported that back about an hour ago, so they are burning the midnight oil in Asia.

I am supplying the files and they are installing them. It has to do with the Unicode, double-byte characters. When VB6 reads them on their machines, the conversion to ASCII strings is not being done consistently. I actually have two files doing the same thing. Strangely ebough, two other files are working OK with the same binary read shown in Posts 1 and 3. The bytes are all being read, but simple characters or strings like "Hello" are not being found on two others. These two contain sound and picture data with simple commoin string separators such as as "Sound File 01" or "Pic File 01".

The string defining App.Path and AppDataPath is OK. I checked that out over the weekend, so the files are being found.

Is there an other read procedure, such as a byte variable we could use and then convert that to a string to get rid of the double-byte problem? Just a thought. I'm grasping at straws.

Grasping too. Here's the idea I was trying to get at.
Your code:

Code:

---

      Dim MyData As String, StartRead As Long, EndRead as Long
10    Open AppPath & "Stems" For Binary As #1
20    MyData = Space$(LOF(1))
30    Get #1, , MyData
40    Close #1
50    StartRead = InStr(MyData, "Hello")
60    EndRead = InStr(StartRead, MyData, ".")

---

My thought is that something is being lost in translation. You provided them the Stem file and if they give you the result of what your app read in, you can compare the two for any differences. Modifying your code below, if they run it an give you the file back, you can compare.

Code:

---

      Dim MyData As String, StartRead As Long, EndRead as Long
    Open AppPath & "Stems" For Binary As #1
    MyData = Space$(LOF(1))
    Get #1, , MyData
    Close #1

    Dim bData() As Byte
    ReDim bData(1 To LenB(MyData))
    CopyMemory bData(1), ByVal StrPtr(MyData), UBound(bData)
    Open AppPath & "Stems.tst" For Binary As #2
    Put #2, 1, bData()
    Close #2
    ' get Stems.tst back from them for testing/review

---

If the Stems you provided them is at all different than Stems.tst they gave you back, you might have something to go on.

Fox, we do know that the files that are having trouble contain picture and sound data intermingled with simple ASCII (ANSI) characters. These were created from .wmp files and .gif images. When the Chinese machines read them with my code in posts #1 and #3, the "translation" as you call it is being lost.

Assume that I packed about 100 pictures in one resource file and 100 sound tracks in the other, primarily to save file overhead space. All of these could likely be exploded back out and installed using standard .gif and .wma formats, but I am trying to avoid loading 200 files on either the App.Path or the AppDataPath. My file packing procedure works like a charm until it gets bashed by the multi-byte Chinese Language setting during the binary Open and Read.

Somehow we have to strip that out and hang onto what the American (English) machines are storing. Otherwise, I may have no choice but to load the users' hard drive with 200 separate audio and image files rather than 2 resource files.

Ok, going on the assumption that translation is lost and trying to avoid using APIs to read the files, maybe this might be a worthwhile test.... Don't let VB read the string, you write the string. CopyMemory API is in use however:

Code:

---

      Dim MyData As String, StartRead As Long, EndRead as Long
Dim bData() As Byte
    Open AppPath & "Stems" For Binary As #1
    ReDim bData(1 To LOF(1))
    Get #1, 1, bData()
    Close #1
MyData = String$(UBound(bData), vbNullChar)
CopyMemory ByVal StrPtr(MyData), bData(1), UBound(bData)
Erase bData()

---

The above is a slight change to what you were doing. I don't know if it will work, but one thing is for sure: the MyData string will contain what is in the file, byte for byte. There is no direct VB conversion from binary to string.

Thanks a bunch. I assume that this is the CopyMemory API that I need to declare at the top:

Code:

---

Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (pDst As Any, pSrc As Any, ByVal ByteLen As Long)

---

I'll drop it into the code and check it. If it works on my machine, I'll transport a new .exe to China and report back. At last resort, we break out all the packed files.

One last clue. The two files that read correctly on the Asian machines using my simple code in Posts #1 and #3 were .rtf files that I read in as strings. They may have had some embedded pictures but not raw .Gif's or .Wma's as these do.

Quote:

---

Originally Posted by Code Doc

Thanks a bunch. I assume that this is the CopyMemory API that I need to declare at the top:

Code:

---

Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (pDst As Any, pSrc As Any, ByVal ByteLen As Long)

---

---

Yes. Test quickly on your system before forwarding along.

Edited: One other thing I would recommend: Force binary comparison in your InStr() so VB doesn't try to do case conversion. This is default if one does not add "Option Compare Text" to their form/module. By you can still implicitly call it:
Example > StartRead = InStr(1, MyData, "Hello", vbBinaryCompare)

Fox, I fear that it failed. Here are the first 30 bytes of the file that the API code is yielding for MyData in the image file:
???????????????Aa????????????

Here is what it should be yielding:
M-HTOEFLPic 1-01.jpgÿØÿàJFIF

These are .jpg files that I packed in there, not .gif's that I said earlier. Any idea why it failed? The length of MyData does equal the file size and no error was reported until I started reading with Instr().

Ugh. Sorry. Hmmm....

Sounds like the resolution is not to use strings, but that would mean rewriting your "packer" and avoid string functions on the array. Or possibly using APIs vs VB's built-in string manipulation methods.

P.S. I made a mistake on the length of the string (it is too long), but doesn't matter here since it is not working.

Quote:

---

Originally Posted by LaVolpe

Ugh. Sorry. Hmmm....

Sounds like the resolution is not to use strings, but that would mean rewriting your "packer" and avoid string functions on the array. Or possibly using APIs vs VB's built-in string manipulation methods.

P.S. I made a mistake on the length of the string (it is too long), but doesn't matter here since it is not working.

---

I changed

Get #1, 1 , bData()

to

Get #1, , bData()

However, I doubt that means anything. If 1 is omitted, the first byte is assumed. I have a feeling my cool file packer is dead meat. A ton of code will have to be rewritten and the installer will take hours to adjust. :sick:

What confuses me most is that an identical file reading procedure works on the RTF files but not these two files with images and audio. To me, that is senseless. Things like this make me yearn for the DOS days.

LaVolpe's solution doesn't work because two bytes are pushed to one character, while Code Doc's code relies on ANSI conversion that results in one byte = one character.

I'll start with a simple test:

Code:

---

      Dim MyData As String, StartRead As Long, EndRead As Long, MyBytes() As Byte
10    Open AppPath & "Stems" For Binary As #1
20    ReDim MyBytes(LOF(1) - 1)
30    Get #1, , MyBytes
40    Close #1
45    MyData = StrConv(MyBytes, vbUnicode, 1033) ' force US English locale conversion
50    StartRead = InStr(MyData, "Hello")
60    EndRead = InStr(StartRead, MyData, ".")

---

Merri, I will test this immediately and report back. I have a gut feeling that this is the solution.

What amazes me most is that the RTF files that I was reading with an identical procedure to Post #1 all seemed to work, provided I made no attempt to swap ASCII values with a decryption routine. That routine worked flawlessly on USA machines and errored on Asian machines. Regardless, I may use your procedure for those files as well and restore the encryption/decryption procedure after MyData is defined correctly by StrConv().