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 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user