Vietnamese support!
Vietnamese support!
Hello, I am a v7.0 user to start.
I think the inquiry is pretty simple.
We have a customer who wants Vietnamese characters to be shown on the chart.
We found that there are certain words which need 4 bytes in order to be displayed correctly but Teechart uses only 2 bytes even though it has Vietnamese support.
You may see the list of words from the link below.
http://www.m2soft.co.kr/report/sjs/RDMPL001.xml
I appreciate it if you could look into this problem.
I will wait for your reply.
Thanks in advance.
I think the inquiry is pretty simple.
We have a customer who wants Vietnamese characters to be shown on the chart.
We found that there are certain words which need 4 bytes in order to be displayed correctly but Teechart uses only 2 bytes even though it has Vietnamese support.
You may see the list of words from the link below.
http://www.m2soft.co.kr/report/sjs/RDMPL001.xml
I appreciate it if you could look into this problem.
I will wait for your reply.
Thanks in advance.
Hello,
TeeChart AX interfaces support WideString. WideString accepts multi-byte character input, that may be 1, 2 , 4, etc bytes. That should work correctly in Vietnamese native machines. There are limitations in non native machines (eg. English operating system and non-unicode (2 byte) locale set to Vietnamese) because strings used internally in TeeChart AX are Ansistring and there have been problems in the conversion from Widestring. There is a test version on the TeeChart Customer download page that offers improved support for the handling of Widestrings in all environments, any feedback would be welcome on that version.
With thanks.
Regards,
Marc Meumann
TeeChart AX interfaces support WideString. WideString accepts multi-byte character input, that may be 1, 2 , 4, etc bytes. That should work correctly in Vietnamese native machines. There are limitations in non native machines (eg. English operating system and non-unicode (2 byte) locale set to Vietnamese) because strings used internally in TeeChart AX are Ansistring and there have been problems in the conversion from Widestring. There is a test version on the TeeChart Customer download page that offers improved support for the handling of Widestrings in all environments, any feedback would be welcome on that version.
With thanks.
Regards,
Marc Meumann
Steema Support
Hello again.
I still have failed to display Vietnam characters correctly on the Vietnam OS.
I have attached a sample project. If you just run the project, you may see that Vietnam characters are broken.
I would greatly appreciate it if you could take a look at this project and tell me a solution.
Before you run the project, please put aaa.xml file under C:/ (ie. C:/aaa.xml).
Many thanks.
http://www.m2soft.co.kr/report/sjs/TeeTest_7008.zip
Sample project may be downloaded from here.
http://www.m2soft.co.kr/report/sjs/TeeTestSrc.zip
Source code may be downloaded from here.
I still have failed to display Vietnam characters correctly on the Vietnam OS.
I have attached a sample project. If you just run the project, you may see that Vietnam characters are broken.
I would greatly appreciate it if you could take a look at this project and tell me a solution.
Before you run the project, please put aaa.xml file under C:/ (ie. C:/aaa.xml).
Many thanks.
http://www.m2soft.co.kr/report/sjs/TeeTest_7008.zip
Sample project may be downloaded from here.
http://www.m2soft.co.kr/report/sjs/TeeTestSrc.zip
Source code may be downloaded from here.
Hello,
this is really a good time if we can get some response from you.
At least, telling us something like we tested something wrong or there is a new way to test things are very much appreciated.
Our client is getting more anxious by days.
To summarise my inquiry,
we are testing under the Vietnam OS (It is a multi-language WinXP version with the Vietnam Language Pack installed and running) from the first place, hence non-native machine environment isn't something to consider.
We have successfully displayed the 2 bytes Vietnam characters but failed to do so with the 4 bytes Vietnam characters. We spent time to analyze the cause of this outcome but we still couldn't get this working.
Thanks.
this is really a good time if we can get some response from you.
At least, telling us something like we tested something wrong or there is a new way to test things are very much appreciated.
Our client is getting more anxious by days.
To summarise my inquiry,
we are testing under the Vietnam OS (It is a multi-language WinXP version with the Vietnam Language Pack installed and running) from the first place, hence non-native machine environment isn't something to consider.
We have successfully displayed the 2 bytes Vietnam characters but failed to do so with the 4 bytes Vietnam characters. We spent time to analyze the cause of this outcome but we still couldn't get this working.
Thanks.
Hello,
Sorry not to get a quick reply to you on this. We've run tests and we don't yet have a test result that gives you the functionality you require. We are still checking to see if there is any change we can make that will display the characters correctly. I'll post a more definitive answer here within the next two days.
Regards,
Marc Meumann
Sorry not to get a quick reply to you on this. We've run tests and we don't yet have a test result that gives you the functionality you require. We are still checking to see if there is any change we can make that will display the characters correctly. I'll post a more definitive answer here within the next two days.
Regards,
Marc Meumann
Steema Support
Hello,
As a followup... We've done more tests on this on an XP machine set up in Vietnamese. TeeChart can't correctly display all texts in this environment. We believe this is because Microsoft have implemented Vietnamese as a Language Interface Pack, not as a native Windows implementation. As TeeChart AX is not fully Unicode compliant it cannot work with the characters that are not based in the Windows operating system (as would be the case in Japanese or Korean).
To fully support Vietnamese with a TeeChart product you would need to use TeeChart for .NET or TeeChart for Java, both Unicode compliant.
I'm sorry I can't give you a more positive answer.
Regards,
Marc Meumann
As a followup... We've done more tests on this on an XP machine set up in Vietnamese. TeeChart can't correctly display all texts in this environment. We believe this is because Microsoft have implemented Vietnamese as a Language Interface Pack, not as a native Windows implementation. As TeeChart AX is not fully Unicode compliant it cannot work with the characters that are not based in the Windows operating system (as would be the case in Japanese or Korean).
To fully support Vietnamese with a TeeChart product you would need to use TeeChart for .NET or TeeChart for Java, both Unicode compliant.
I'm sorry I can't give you a more positive answer.
Regards,
Marc Meumann
Steema Support
Okay. Here is the thing.
Our customer, to be more specific "Honda", thinks of this as one of important matters and wants this to be fixed. Hence, we are at the place where we have to find the way out.
I think one of other posts, you(or the other person) said if I compile and run my application under the native OS environment (not multi-language version), all the text would be displayed correctly.
Is this true? If it is true, how can I ever do this since there is no Vietnam Windows XP version. Any native OS that handles 2 byte characters would do this (like Korean or Japanese version)?
Could you be more specific about how you handle characters internally? You said you convert string from Widestring to Ansistring in non native machines, and due to this fact, there are certain limitations. Does this mean that you handle characters only with Widestring in native machines?
Vietnamese has some interesting characters. For example, there is a character looks like A with a dot on the top and a comma on the bottom (ie. it would look like .A, as in one character). I think the problem arises when you take one character at a time. If we just say 0x0030 represents 'A' and 0xAAAA represents a dot and comma combination, passing 0x0030 and 0xAAAA separately would cause the displaying failure. I think it is why we get a such display like A? where it is meant to display .A, character. 0xAAAA itself doesn't represent anything, it has its meaning only when you pass it together with 0x0030, A (0xAAAA will try to decorate the character passed right before).
Take all the string at one time and pass them to Windows API could be one of solutions. I don't know.
I just want to tell you everything I know, since we are very anxious about this matter.
To summarise my inquiry, I just would like to know whether this can never be done.
We believed the TeechartAX is Unicode supported and now we are in some awkward situation with Honda.
Regards,
Seth
Our customer, to be more specific "Honda", thinks of this as one of important matters and wants this to be fixed. Hence, we are at the place where we have to find the way out.
I think one of other posts, you(or the other person) said if I compile and run my application under the native OS environment (not multi-language version), all the text would be displayed correctly.
Is this true? If it is true, how can I ever do this since there is no Vietnam Windows XP version. Any native OS that handles 2 byte characters would do this (like Korean or Japanese version)?
Could you be more specific about how you handle characters internally? You said you convert string from Widestring to Ansistring in non native machines, and due to this fact, there are certain limitations. Does this mean that you handle characters only with Widestring in native machines?
Vietnamese has some interesting characters. For example, there is a character looks like A with a dot on the top and a comma on the bottom (ie. it would look like .A, as in one character). I think the problem arises when you take one character at a time. If we just say 0x0030 represents 'A' and 0xAAAA represents a dot and comma combination, passing 0x0030 and 0xAAAA separately would cause the displaying failure. I think it is why we get a such display like A? where it is meant to display .A, character. 0xAAAA itself doesn't represent anything, it has its meaning only when you pass it together with 0x0030, A (0xAAAA will try to decorate the character passed right before).
Take all the string at one time and pass them to Windows API could be one of solutions. I don't know.
I just want to tell you everything I know, since we are very anxious about this matter.
To summarise my inquiry, I just would like to know whether this can never be done.
We believed the TeechartAX is Unicode supported and now we are in some awkward situation with Honda.
Regards,
Seth
That sounds just good to us...
We greatly appreciate all of your efforts to solve this problem.
Just like any client would want to know, it would be good that you let us know when we can get some reponse from you. I am not saying to be exact but roughly you know. I hope you understand we are in a situation where we have to give some kind of reponse to the client.
Many Thanks.
Regards,
Seth
We greatly appreciate all of your efforts to solve this problem.
Just like any client would want to know, it would be good that you let us know when we can get some reponse from you. I am not saying to be exact but roughly you know. I hope you understand we are in a situation where we have to give some kind of reponse to the client.
Many Thanks.
Regards,
Seth
Hello Seth,
We can't be sure that we can offer a solution yet, but we should know in a little over a week from now whether the modification we are working on can resolve the issue or not. If the answer is positive we would be able to make a test version available at that time.
Regards,
Marc
We can't be sure that we can offer a solution yet, but we should know in a little over a week from now whether the modification we are working on can resolve the issue or not. If the answer is positive we would be able to make a test version available at that time.
Regards,
Marc
Steema Support
Hello,
I thank you again for all of your efforts and your work.
We also tested a number of things and confirmed that Vietnam characters are all displayed correctly.
But we still do have one inquiry to make.
""[Some String Value]" is not a valid component name" error occurs when I pass some string value to the SetName method. ie. TChart1.Series(0).SetName(str);
However, TChart1.Series(0).SetTitle(str);, this didn't give any malfunction for displaying chart.
If you could fix this one, we would like to get a CAB file that we can provide to the customer.
Since this one is labeled as the test version, we also would like to know whether we need to provide the CAB to the customer again when the final official version comes out.
Regards,
Seth
I thank you again for all of your efforts and your work.
We also tested a number of things and confirmed that Vietnam characters are all displayed correctly.
But we still do have one inquiry to make.
""[Some String Value]" is not a valid component name" error occurs when I pass some string value to the SetName method. ie. TChart1.Series(0).SetName(str);
However, TChart1.Series(0).SetTitle(str);, this didn't give any malfunction for displaying chart.
If you could fix this one, we would like to get a CAB file that we can provide to the customer.
Since this one is labeled as the test version, we also would like to know whether we need to provide the CAB to the customer again when the final official version comes out.
Regards,
Seth
Hello Seth,
Thanks for the feedback. We had expected some outstanding issues as the changes are quite far-reaching. We'll fix this particular one and put a new test version up (An update went up on the 4th too, to fix an issue related to manual data entry without Labels).
With respect CAB file. We'll do a few more tests and prepare a test CAB version. You will most likely need an updated CAB later when we make an official release but we'll increment version numbers so CAB update can be automated.
Regards,
Marc
Thanks for the feedback. We had expected some outstanding issues as the changes are quite far-reaching. We'll fix this particular one and put a new test version up (An update went up on the 4th too, to fix an issue related to manual data entry without Labels).
With respect CAB file. We'll do a few more tests and prepare a test CAB version. You will most likely need an updated CAB later when we make an official release but we'll increment version numbers so CAB update can be automated.
Regards,
Marc
Steema Support