MSComm on Japanese/Chinese language Windows 
Author Message
 MSComm on Japanese/Chinese language Windows

We have a VB6 application that runs fine on all versions
of Windows, 95, 98, Me, 2K, XP, etc.

However, we have had two complaints lately that the
application will not work. Both complaints came from Asia;
one from Japan and one from Taiwan. In both cases, the
application fails to communicate to an attached device via
MSCOMM. The application uses MSCOMM in binary mode. Code
is built and packaged using SP5.

Does anyone know of any issues with MSCOMM and foreign
language windows?

Thanks.



Sat, 25 Sep 2004 05:05:22 GMT  
 MSComm on Japanese/Chinese language Windows
Hi,

If your are sending and receiving binary data in DBCS enabled systems you
must use the MSComm property .InputMode = comInputModeBinary, and buffer
transmit data in an array of type Byte.  If you use a String to buffer data,
Unicode conversion will corrupt it.

I have complete information (and example code) in my book.  See below.

--
Richard Grier  (Microsoft Visual Basic MVP)

See www.hardandsoftware.net for contact information.

Author of Visual Basic Programmer's Guide to Serial Communications, 3rd
Edition ISBN 1-890422-27-4 (391 pages) published February 2002.



Sat, 25 Sep 2004 07:57:22 GMT  
 MSComm on Japanese/Chinese language Windows
Dick -

Thanks for the response.

We use MSComm in binary input mode already, because the
serial device interface is binary (not ASCII).

If we had to rewrite our application to handle everything
that is currently handled as a string manipulation to a
byte array manipulation, it would be a major rewrite. Is
this just an issue at the interface to MSComm? That is,
can we manipulate our data as a string, then simply
convert our string to a byte array before passing it to
the MSComm .Output property?

Our customer in Japan captured some traffic on a serial
analyzer and, oddly, the traffic (at least what he caught)
appears fine - both transmit and receive - but the
application is apparently not happy with waht it finally
receives fom MSComm.

Thanks,
Rich

Quote:
>-----Original Message-----
>Hi,

>If your are sending and receiving binary data in DBCS
enabled systems you
>must use the MSComm property .InputMode =

comInputModeBinary, and buffer
Quote:
>transmit data in an array of type Byte.  If you use a

String to buffer data,
Quote:
>Unicode conversion will corrupt it.

>I have complete information (and example code) in my
book.  See below.

>--
>Richard Grier  (Microsoft Visual Basic MVP)

>See www.hardandsoftware.net for contact information.

>Author of Visual Basic Programmer's Guide to Serial
Communications, 3rd
>Edition ISBN 1-890422-27-4 (391 pages) published February
2002.

>.



Sun, 26 Sep 2004 02:36:45 GMT  
 MSComm on Japanese/Chinese language Windows
Hi,

If we had to rewrite our application to handle everything
that is currently handled as a string manipulation to a
byte array manipulation, it would be a major rewrite. Is
this just an issue at the interface to MSComm? That is,
can we manipulate our data as a string, then simply
convert our string to a byte array before passing it to
the MSComm .Output property?
<<

Sorry, this has nothing to do with MSComm, per se.  VB supports Unicode
strings (two bytes per character).  That causes no real trouble for non-DBCS
systems, but DBCS character mapping is non-ASCII/ANSI.  Thus, byte values
higher than &H7F (128-255 decimal) are not mapped as you expect.  So, (VB
documentation discusses this issue, but it is not completely obvious),
binary data should not use Strings for data storage or manipulation.  AFAIK,
there is no good way around this.

And, yes, this is a receive problem, not transmit.  However, for consistency
both receive and transmit should use arrays of Bytes (IMO).  They are only
absolutely required for receive data.  You can write routines that emulate
InStr, Mid functions, etc., for byte arrays, with some effort.  However, the
Mid statement (and equivalent Left and Right statements) are more difficult.

You can try the StrConv function to convert to and from arrays of type Byte
and Strings.  However, I think (don't know for sure) that these may fail.
What you would have to do is to use the optional LCID argument to specify
the locale for North America.  I suppose that it might work.  However, it
would have to be tested on a Japanese OS to be sure.

Sorry I cannot offer a better solution.  However, I think that the only
really satisfactory answer is to go the extra mile and change your binary
data buffering mechanism.

Dick

--
Richard Grier  (Microsoft Visual Basic MVP)

See www.hardandsoftware.net for contact information.

Author of Visual Basic Programmer's Guide to Serial Communications, 3rd
Edition ISBN 1-890422-27-4 (391 pages) published February 2002.



Sun, 26 Sep 2004 11:45:22 GMT  
 MSComm on Japanese/Chinese language Windows
OK,{*filter*}. Thanks for the info. From what you have said, I
feel certain that our problem has something to do with the
DBCS issue, so at least I have a plan of attack.

I'm hopefully getting a copy of W2K-JP today, so I'll be
able to beat on it, and find out what works and what
doesn't.

Regards,
Rich

Quote:
>-----Original Message-----
>Hi,

>If we had to rewrite our application to handle everything
>that is currently handled as a string manipulation to a
>byte array manipulation, it would be a major rewrite. Is
>this just an issue at the interface to MSComm? That is,
>can we manipulate our data as a string, then simply
>convert our string to a byte array before passing it to
>the MSComm .Output property?
><<

>Sorry, this has nothing to do with MSComm, per se.  VB
supports Unicode
>strings (two bytes per character).  That causes no real

trouble for non-DBCS
Quote:
>systems, but DBCS character mapping is non-ASCII/ANSI.  
Thus, byte values
>higher than &H7F (128-255 decimal) are not mapped as you
expect.  So, (VB
>documentation discusses this issue, but it is not

completely obvious),
Quote:
>binary data should not use Strings for data storage or

manipulation.  AFAIK,
Quote:
>there is no good way around this.

>And, yes, this is a receive problem, not transmit.  

However, for consistency
Quote:
>both receive and transmit should use arrays of Bytes

(IMO).  They are only
Quote:
>absolutely required for receive data.  You can write

routines that emulate
Quote:
>InStr, Mid functions, etc., for byte arrays, with some

effort.  However, the

- Show quoted text -

Quote:
>Mid statement (and equivalent Left and Right statements)
are more difficult.

>You can try the StrConv function to convert to and from
arrays of type Byte
>and Strings.  However, I think (don't know for sure) that
these may fail.
>What you would have to do is to use the optional LCID
argument to specify
>the locale for North America.  I suppose that it might
work.  However, it
>would have to be tested on a Japanese OS to be sure.

>Sorry I cannot offer a better solution.  However, I think
that the only
>really satisfactory answer is to go the extra mile and
change your binary
>data buffering mechanism.

>Dick

>--
>Richard Grier  (Microsoft Visual Basic MVP)

>See www.hardandsoftware.net for contact information.

>Author of Visual Basic Programmer's Guide to Serial
Communications, 3rd
>Edition ISBN 1-890422-27-4 (391 pages) published February
2002.

>.



Mon, 27 Sep 2004 00:54:32 GMT  
 MSComm on Japanese/Chinese language Windows


Fri, 19 Jun 1992 00:00:00 GMT  
 MSComm on Japanese/Chinese language Windows
Dick -

I was able to get around this problem without *completely*
rewriting my application. By using ChrB(), LeftB(), MidB
(), etc. rather than Chr(), Left(), Mid(), etc., I now
keep all strings being constructed for transmission as
binary rather than unicode or dbcs.

The same thing works for receive, with the exception that
mscomm.input must be read initially into a byte array,
from whence it can be packed into a binary string, after
which the binary string functions can operate on it.

StrConv() is of no help in this problem.

I agree with you that, starting fresh, using byte arrays
throughout is probably the best solution, but this works,
and saved a lot of rewrite/retest time.

Thanks for you help. It could have taken days for me to
figure out what was going on otherwise.

Regards,
Rich

Quote:
>-----Original Message-----
>Hi,

>If we had to rewrite our application to handle everything
>that is currently handled as a string manipulation to a
>byte array manipulation, it would be a major rewrite. Is
>this just an issue at the interface to MSComm? That is,
>can we manipulate our data as a string, then simply
>convert our string to a byte array before passing it to
>the MSComm .Output property?
><<

>Sorry, this has nothing to do with MSComm, per se.  VB
supports Unicode
>strings (two bytes per character).  That causes no real

trouble for non-DBCS
Quote:
>systems, but DBCS character mapping is non-ASCII/ANSI.  
Thus, byte values
>higher than &H7F (128-255 decimal) are not mapped as you
expect.  So, (VB
>documentation discusses this issue, but it is not

completely obvious),
Quote:
>binary data should not use Strings for data storage or

manipulation.  AFAIK,
Quote:
>there is no good way around this.

>And, yes, this is a receive problem, not transmit.  

However, for consistency
Quote:
>both receive and transmit should use arrays of Bytes

(IMO).  They are only
Quote:
>absolutely required for receive data.  You can write

routines that emulate
Quote:
>InStr, Mid functions, etc., for byte arrays, with some

effort.  However, the

- Show quoted text -

Quote:
>Mid statement (and equivalent Left and Right statements)
are more difficult.

>You can try the StrConv function to convert to and from
arrays of type Byte
>and Strings.  However, I think (don't know for sure) that
these may fail.
>What you would have to do is to use the optional LCID
argument to specify
>the locale for North America.  I suppose that it might
work.  However, it
>would have to be tested on a Japanese OS to be sure.

>Sorry I cannot offer a better solution.  However, I think
that the only
>really satisfactory answer is to go the extra mile and
change your binary
>data buffering mechanism.

>Dick

>--
>Richard Grier  (Microsoft Visual Basic MVP)

>See www.hardandsoftware.net for contact information.

>Author of Visual Basic Programmer's Guide to Serial
Communications, 3rd
>Edition ISBN 1-890422-27-4 (391 pages) published February
2002.

>.



Tue, 28 Sep 2004 06:14:23 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. Trouble Displaying Japanese/Chinese

2. Localize into Japanese and Chinese?

3. FM20.DLL problem in JAPANESE language

4. Japanese e- mail in diff comp language HELP

5. Problems with FM20 dll in japanese language

6. Experience with using different languages (e.g. Japanese)

7. XPressSideBar control and Japanese Language

8. help:display european language on Chinese OS

9. Chinese language in Visual Basic 4.0

10. Chinese language in Visual Basic 4.0

11. help:display European language on Chinese OS

12. help:display European language on Chinese OS

 

 
Powered by phpBB® Forum Software