PeekS, PokeS and string conversion

[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?

[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.

[Tipperton]

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

[pdwyer]

Personally I just deal with unicode as needed, I don't change the compile type.

[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

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.

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.

[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..

[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

[Fred]

Just remove the '@', it's a string expected.

[Tipperton]

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!