Actually - will take a different approach with this one.
There is no point trying to replicate clarion's impleementation of locale management when Java comes with a far superior implementation. locale() function is typically called once in entire life of the program, and most of the time, java will get the right default locale anyway.
So solution is simple - ignore locale function and instead utilise java's locale capabitilies.
Specifics:
* use DateFormatSymbols to help with DateFormatter
* For String internal encoding and decoding, use CharSet.defaultCharset()
** for string serialization/deserialization
** for ASCII and BASIC file access (DOS is to remain as is - since it is intended to be a 'binary' reader)
* For message button text - use java resource files : ResourceBundle.getBundle(name,locale)
* For error message text - use java resource files : ResourceBundle.getBundle(name,locale)
* For string comparators - use java.text.Collator
* For queue Sorts - use java.text.Collator + java.text.CollatorKey
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Implementing charsets under ClarionString serialization/deserialization is proving tricker than first expected. Have an unchecked implementation. But there is a serious problem: Charset encoders and decoders are not perfectly symetrical. It is possible to decode 'garbage' byte stream and then when you reencode you get a different result.
This is a critical problem when your ClarionString is result of, say an assignment or an OVER() of a clarion group that contains things like numbers etc. Certainly messes up things like SQL File position operations.
Thinking now is to not include string serialization/deserialization as part of locale implementation. The only benefit of this anyway deals with condition where user performs an OVER, string to string, or OVER on all string group. Rare programming conditions that can be readily worked around if needed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Actually - will take a different approach with this one.
There is no point trying to replicate clarion's impleementation of locale management when Java comes with a far superior implementation. locale() function is typically called once in entire life of the program, and most of the time, java will get the right default locale anyway.
So solution is simple - ignore locale function and instead utilise java's locale capabitilies.
Specifics:
* use DateFormatSymbols to help with DateFormatter
* For String internal encoding and decoding, use CharSet.defaultCharset()
** for string serialization/deserialization
** for ASCII and BASIC file access (DOS is to remain as is - since it is intended to be a 'binary' reader)
* For message button text - use java resource files : ResourceBundle.getBundle(name,locale)
* For error message text - use java resource files : ResourceBundle.getBundle(name,locale)
* For string comparators - use java.text.Collator
* For queue Sorts - use java.text.Collator + java.text.CollatorKey
DateFormatSymbols, ASCII and BASCI File drivers now updated.
Todo : string internal coding. String comparator. Resource bundles
Implementing charsets under ClarionString serialization/deserialization is proving tricker than first expected. Have an unchecked implementation. But there is a serious problem: Charset encoders and decoders are not perfectly symetrical. It is possible to decode 'garbage' byte stream and then when you reencode you get a different result.
This is a critical problem when your ClarionString is result of, say an assignment or an OVER() of a clarion group that contains things like numbers etc. Certainly messes up things like SQL File position operations.
Thinking now is to not include string serialization/deserialization as part of locale implementation. The only benefit of this anyway deals with condition where user performs an OVER, string to string, or OVER on all string group. Rare programming conditions that can be readily worked around if needed.
String multichar issue resolved. Only one outstanding item : resource bundles.