[Gambas-user] Bad string conversion etc.

[Rolf-Werner Eilert]

Benoit Minisini schrieb:
> On mercredi 01 octobre 2008, Rolf-Werner Eilert wrote:
>> Still trying to convert a Gambas1 app to Gambas2. Basically, it begins
>> to run. However, there are strange error message at some points, and I
>> do not understand what causes them.
>>
>> 1. This line
>>
>> po = links.Find(wert[8], gb.Language)
>>
>> results in "Bad string conversion". Strange to me, as I do not see any
>> conversion here.
> 
> By using gb.language, you force a locale-aware comparison of the strings 
> inside links. This locale-aware string comparison is implemented by first 
> converting the strings into 32 bits Unicode, and that conversion apparently 
> fails. What does the links array contain?


It contains a list of field names or "variable" names from a database. 
You are right, if I leave gb.Language away, the thing works just fine.

BUT: If I use gb.Text, it works too. And in the help I find that 
gb.Language isn't mentioned at all - is there a deeper reason for this 
to be left out for the find method?

This brings me to a new question that just arose:

When running the program, I found that the list of persons' names wasn't 
sorted anymore or not sorted correctly. So I started to play with the 
three options for .Sort() and to compare them to the list in the 
original app running under Gambas1. You know, we got Umlauts in German, 
so UTF-8 plays a role. And there are people with accents in their names 
like in French or the name begins with a non-capital letter.

Under Gambas1, when I used Sort(gb.Lang) everything was sorted just the 
way I would expect it from what is usual in a German office environment, 
for instance:

- ü is treated like ue, ö like oe, ä like ae,
- ß like ss
- and the sort is not case sensitive i. e. de = De

When I use gb.Language now, the name "de Witt" is hidden at the end of 
the list, ü is treated like they do in Swedish (at the end of all u...s, 
i. e. "Müller" is set after "Munk" and not before it) etc. The options 
gb.Text and gb.Binary aren't useful here, either.

What is the reason for this?


>> 2. Here "Maske" is a tabstrip. First it is checked that it has enough
>> tabs. Then the "current" tab is set.
>>
>> IF CInt(wert[0]) > Maske.Count THEN Maske.Count = CInt(wert[0])
>> Maske.Index = CInt(wert[0] - 1)
>>
>> Gambas will stop at the second line complaining "Type mismatch: wanted
>> Number got String instead".
>>
>> Well, wert[0] at this time contains the string "1". This is a string
>> with a number, and CInt should convert it to a numeric value, shouldn't
>> it? (I tested to leave out the "- 1", this resulted in "Bad index" for
>> the tabstrip!)
> 
> This is a little bug in addition optimization. Anyway, if you want to do 
> arithmetic, do it on numbers, not on strings:
> 
> Maske.Index = CInt(wert[0]) - 1
> 
> Regards,
> 


Yes :-) I think this was a little bug in my brain, although one might 
come up with "the interpreter should understand this". After all, 
Gambas1 did. But you shouldn't be able to mix up a numeric value with a 
string expression, so the error message here seems more correct to me.

Regards

Rolf