Page 1 of 1
PeekS, PokeS and string conversion
Posted: Wed Aug 15, 2007 1:36 am
by Tipperton
In the help file it says:
Note: a combination of PokeS() and PeekS() can be used to perform conversion between the different supported string modes (Ascii, UTF8 and Unicode).
Which is fine but...
For PokeS the format parameter specifies how the string will be poked and for PeekS it specifies how the string will be peeked. The implication is that the string variable will always be in the format (ASCII or Unicode) depending on the compiler setting chosen.
So...
Code: Select all
PokeS(*memory, @source.s, Len(source.s), #PB_Unicode)
destination.s=PeekS(*memory, Len(source.s), #PB_Unicode)
For a program compiled in ASCII would result in no conversion and
Code: Select all
PokeS(*memory, @source.s, Len(source.s), #PB_Unicode)
destination.s=PeekS(*memory, Len(source.s)*2, #PB_Ascii)
Would result a truncated string, it would end at the first zero byte.
Or...
Code: Select all
PokeS(*memory, @source.s, Len(source.s), #PB_Ascii)
destination.s=PeekS(*memory, Len(source.s), #PB_Ascii)
For a program compiled in Unicode would result in no conversion and
Code: Select all
PokeS(*memory, @source.s, Len(source.s), #PB_Unicode)
destination.s=PeekS(*memory, Len(source.s)*2, #PB_Ascii)
Would result a truncated string, it would end at the first zero byte.
What am I missing?
Posted: Wed Aug 15, 2007 2:19 am
by pdwyer
Maybe they are not talking about using a combination to convert one type string to another when all the strings are yours in the first place but handle return values from APIs etc which don't match what you've compiled your code as.
For example if you are compiling as ascii and an API returns a unicode string then you can still go get it and vice versa.
Just a guess though. I agree it's somewhat ambiguous.
Generally a conversion requires you to actually convert one type to another, not just look at a pointer in a different way.
Posted: Wed Aug 15, 2007 2:38 am
by Tipperton
pdwyer wrote:Generally a conversion requires you to actually convert one type to another, not just look at a pointer in a different way.
Agree a real conversion would have you specify both the source and destination formats. Here it seems that for native strings you are restricted to what you configure the project for via the compiler settings.
Maybe what would be better than a global setting for ASCII or Unicode would be having two different string types. For example:
Code: Select all
asciistring.s ; this is an ASCII string
unicodestring.u ; this is a Unicode string
Posted: Wed Aug 15, 2007 2:52 am
by pdwyer
Personally I just deal with unicode as needed, I don't change the compile type.
Posted: Wed Aug 15, 2007 9:19 am
by Demivec
For programs compiled in ASCII :
Code: Select all
PokeS(*memory, source.s,-1, #PB_Unicode) ;would convert a string from the default format of ASCII to a Unicode string located at *memory
destination.s=PeekS(*memory,-1, #PB_Unicode) ;would convert a string at *memory from Unicode to the default ASCII format
For programs compiled in Unicode :
Code: Select all
PokeS(*memory, source.s, -1, #PB_Ascii) ;would convert a string from the default format of Unicode to an ASCII string located at *memory
destination.s=PeekS(*memory, -1, #PB_Ascii) ;would convert a string at *memory from Ascii to the default Unicode format
Tipperton wrote:pdwyer wrote:Generally a conversion requires you to actually convert one type to another, not just look at a pointer in a different way.
Agree a real conversion would have you specify both the source and destination formats. Here it seems that for native strings you are restricted to what you configure the project for via the compiler settings.
A real conversion is performed and both the source and destination formats are always specified. For PokeS the soruce format is the compiled format (i.e. Ascii or Unicode), while the destination is specified by flags (i.e. #PB_Unicode). For PeekS the source format is specified by flags, while the destination format is the compiled format. So to review, one format can be specified by a flag while one or both formats are specified by the compile format (Ascii or Unicode).
The problem is really not conversion but accessing the string in it's current format regardless of the mode the program was compiled in.
Tipperton wrote:Code: Select all
asciistring.s ; this is an ASCII string
unicodestring.u ; this is a Unicode string
I think this would be the way to go. Likewise a char type for each would also be needed. Because of the current format of variable types I run out of sensible types when only single letters are used. I think going to a two letter format would be better. Something like:
Code: Select all
anychar.c ;1 or 2 bytes depending if compile format is Ascii or unicode
asciichar.c1 ;1 byte unsigned value for characters or byte
unicodechar.c2 ;2 byte unsigned value for characters or word
;and while we're at it throw in some of these to round out the possibilities for non string variables
unsignedlong.c4 ;4 byte unsigned for long
unsignedquad.c8 ;8 byte unsigned for quad
*Edit:removed a leftover '@' from a quote (I corrected one, not the other), change the suggested feature to remove float types.
Posted: Wed Aug 15, 2007 9:34 am
by Fred
It all depends of what you are wanting to do. If you wnat to convert strings befire passing it to an external functions (like third libs/dll etc.) just use a pseudotype in the function declaration and it will work everywhere. Having 2 types of strings at runtime isn't possible as all string functions will have to handle both type everytime..
Posted: Wed Aug 15, 2007 11:08 am
by ABBKlaus
i am missing something here
Code: Select all
PokeS(*memory, @source.s, -1, #PB_Ascii) ;would convert a string from the default format of Unicode to an ASCII
Bad parameter type: a string is expected
Posted: Wed Aug 15, 2007 11:31 am
by Fred
Just remove the '@', it's a string expected.
Posted: Wed Aug 15, 2007 12:26 pm
by Tipperton
Fred wrote:just use a pseudotype in the function declaration and it will work everywhere.
Hmm.... hadn't thought of using a pseudotype, I'll have to look into that!
Thanks for the idea Fred!
