Hi,
We have a GUI software that is running on win NT/2K/XP/95/98/ME. The
software is developed using Visual Studio 6 and has a common source code
base for all supported Win OS.
The GUI software interacts with a hardware to get running data to be
displayed on the UI. The GUI is to be internationalized. The Hardware does
not understand UNICODE and can understand only ASCII.
For most of the communication we translate the UNICODE bytes into a BYTE
stream and push it into the Camera for storage (this is the way it has to
be). This works for most of the features.
However we are facing a typical problem with respect to a list of names
sent by the Camera to the UI. Below is the description of the problem.
The Names are set into the hardware ONE by ONE. The camera stores this as
byte stream separated by a '~' character. Thus if I do a SetName() thrice
for Name1, Name2 and Name3 it would be stored as Name1~Name2~Name3 in the
Camera. When asked to GetNames() the Camera returns the complete byte stream
"Name1~Name2~Name3". When everything was ASCII the parsing algorithm to
achieve this was simple. Now however the scenario is different. The Name1,
Name2 and Name3 are all in UNICODE whereas ~ is in ASCII. When we get the
byte stream there might be a chance that the first or second byte of some
UNIOCDE character might correspond to ASCII ~, and the parsing algorithm
might fail.
The Software needs to support all languages possible. What we want to know
is, IS there a ASCII BYTE (SINGLE BYTE) that does not correspond to any of
the UNICODE BYTE set (all languages included) (FIRST or SECOND). Is there
some kind of a reservation on BYTE, say for example, FF which will not be
used by the UNICODE BYTE character set?
We do not want to change the camera code. However if need be we can do
minimal modifications to the camera firmware code.
Alternatively is there any way for the camera code to understand if the
byte stream sent to it is in UNICODE? For example if the GUI sends a BYTE
STREAM "Name1" is it possible for the Camera to identify that the BYTE
STREAM sent is UNICODE and NOT ASCII ( by checking the first byte or
something like that... ).
Please let us know at the earliest. We are trying our max but are not able
to figure out a good simple solution.