Apache OpenOffice (AOO) Bugzilla – Issue 85036
VBA: strconv function is not supported
Last modified: 2017-05-20 09:32:10 UTC
In VBA, the StrConv function returns a string converted as specified. For example: StrConv ("tech on the net", 1) 'would return "TECH ON THE NET" StrConv ("TECH ON THE NET", 2) 'would return "tech on the net" StrConv ("TECH ON THE NET", 3) 'would return "Tech On The Net" the StrConv function is not supported in OOo basic
will add to npower10
Created attachment 51771 [details] patch for implementation
Created attachment 51772 [details] test document
The patch is added to cws npower10
fong mark as fixed if it is so ( which I presume it is )
fixed in npower10
Created attachment 53156 [details] test document for QA
As shown in the following result log the StrConv function succeeded in the following CWS build: O3-build-2457-npower10-install_set Log File Results: Test run started : 06/16/2008 03:39:58 PM BEGIN StrConv TEST START : Test StrConv function ITEM Assertion OK : Converts the string to uppercase characters:ABC EFG HIJ ITEM Assertion OK : Converts the string to lowercase characters:abc efg hij ITEM Assertion OK : Converts the first letter of every word in string to uppercase:Abc Efg Hij ITEM Assertion FAIL : Converts narrow (single-byte) characters in string to wide ITEM Assertion FAIL : Converts wide (double-byte) characters in string to narrow (single-byte) characters.£Ã£Â£Ã£Ä£ÅVB¥ì¥¹¥Â¥å©` ITEM Assertion FAIL : Converts Hiragana characters in string to Katakana characters..¤Ã¤Ê¤Ã¤ã¤ó ITEM Assertion FAIL : Converts Katakana characters in string to Hiragana characters..¥åʥåã¥ó ITEM Assertion FAIL : Converts the string from Unicode, the lenght is : 15 ITEM Assertion OK : Converts the string to Unicode: Éú£ÊÃABC TEST OK : Test StrConv function END StrConv Test run finished : 06/16/2008 03:39:58 PM
It looks like the Unicode Test passes on the Windows machine whereas the Linux build failed: ie... ITEM Assertion OK : Converts the string from Unicode, the lenght is : 9 Verified in the following npower10 build with the updated test document: Win-XP2-503-npower10-install_set.zip Test run started : 06/24/2008 05:14:23 PM BEGIN StrConv TEST START : Test StrConv function ITEM Assertion OK : Converts the string to uppercase characters:ABC EFG HIJ ITEM Assertion OK : Converts the string to lowercase characters:abc efg hij ITEM Assertion OK : Converts the first letter of every word in string to uppercase:Abc Efg Hij ITEM Assertion FAIL : Converts narrow (single-byte) characters in string to wide ITEM Assertion FAIL : Converts wide (double-byte) characters in string to narrow (single-byte) characters.£Ã£Â£Ã£Ä£ÅVB¥ì¥¹¥Â¥å©` ITEM Assertion FAIL : Converts Hiragana characters in string to Katakana characters..€Ã€Ê€Ãۋۗ ITEM Assertion FAIL : Converts Katakana characters in string to Hiragana characters..¥åʥåã¥ó ITEM Assertion OK : Converts the string from Unicode, the lenght is : 9 ITEM Assertion OK : Converts the string to Unicode: Éú£ÊÃABC TEST OK : Test StrConv function END StrConv Test run finished : 06/24/2008 05:14:23 PM
Some comments need to add for the test document strcon.xls The conversion types including vbWide and vbNarrow are only applied to East Asia locales. The conversion types including vbKatakana and vbHiragana are only applied to Japan. For there is not default code page in Linux system, the conversion types including vbUnicode and vbFromUnicode are only applied to Windows system.
Assuming that this is about http://msdn.microsoft.com/en-us/library/microsoft.visualbasic.strings.strconv.aspx the implementation (and probably also the testcase) of VbStrConv.Wide and VbStrConv.Narrow is completely wrong. These are not about conversion to/from Unicode or number of bytes per character (double-byte/single-byte) used, but full-width versus half-width characters instead. This is not a text encoding conversion but also a transliteration, use HALFWIDTH_FULLWIDTH and FULLWIDTH_HALFWIDTH. It is also questionable why conversion Hiragana <-> Katakana should fail according to the test case result. Either there are Hiragana/Katakana characters in the string to be converted, or there are not.
->pflin (I have no clue about this, probably worth talking to erAck directly about this, he knows more than a bit about i18n )
pflin -> er, as you see in the attached patch, I really use the a transliteration HALFWIDTH_FULLWIDTH and FULLWIDTH_HALFWIDTH to implement VbStrConv.Wide and VbStrConv. and as the aboved comments, " The conversion types including vbWide and vbNarrow are only applied to East Asia locales. The conversion types including vbKatakana and vbHiragana are only applied to Japan. " I think the test case is inaccurate. It needs to improve.
@pflin: sorry, I was confused by that MS documentation page. It does not mention any Unicode or FromUnicode conversion and given that the "enumeration" doesn't seem to be an enumeration but bit mask constants instead, I was distracted and mislead and started counting cases for bits and overlooked the vbWide and vbNarrow comments and types and was lead to the Unicode conversions being wide/narrow instead ... sorry for fuzz. So, vbUnicode and vbFromUnicode really do exist? Please see the thread with subject "Conversion of LocaleID into codepage" on the dev@l10n mailing list, which actually made me investigating this. In case you're not subscribed, it starts at http://l10n.openoffice.org/servlets/ReadMsg?list=dev&msgNo=10660 in the archive.