Newsgroup: it.comp.lang.visual-basic
Titolo: [!]BUG pauroso o segreto dell'O.S.?

Cercando di risolvere il problema sollevato da Giuseppe (Riordino di
stringhe) mi sono accorto di una stranezza inquietante:
Tutti i caratteri da Chr$(0) a Chr$(129) sono correttamente riconosciuti e
ordinati, ma non isuccessivi.
Se si prendono in  considerazione due caratteri ad es. Chr$(140) e
Chr$(130), si scopre che VB (o Windows) crede che Chr$(140) sia più basso di
Chr$(130).
prova:
StrComp(Chr$(140), Chr$(130), vbBinaryCompare) = -1
MA NON DOVREBBE ESSERE =1 ??????
Dove sta l'errore?
Ciao.

 wrote in message 7e30gi$65f$1...@nslave1.tin.it...

Non ho conferme ufficiali, ma credo sia per il fatto che le stringhe in VB
sono in formato Unicode e non ANSI, e forse la StrComp le elabora in formato
nativo VB (Unicode).
Non ne sono sicuro, ma potrebbe essere così !
Zeross

Zeross
E' quello che ho pensato anch'io, ma in unicode i caratteri sotto il 255
sono composti da Chr$(0) & Chr$(n), e quindi sarebbero comunque in ordine...
Non credo il problema sia qui.
Qualche altra idea (la cosa mi sembra piuttosto pericolosa!)
Ciao.


Mi sono perso il thread, quindi non ho capito la domanda originaria.
Comunque non è vero che in Unicode i caratteri sotto il 255 hanno
lo zero nel byte alto. Prova questo semplice esempio
For i = 0 To 255
     If AscW(Chr$(i)) > 255 Then Debug.Print "Carattere " & chr$(i)
Next i
Ciao Bruno

...


Hai ragione, l'intel lavora al contrario (valida alleata della M$) e quindi
lo zero sta nel byte a destra, che comunque è il byte più significativo
(intel usa codifica little endian).
Ma il problema rimane.
Ecco il post originario, chissà se conosci la risposta:
------------------------------
Cercando di risolvere il problema sollevato da Giuseppe (Riordino di
stringhe) mi sono accorto di una stranezza inquietante:
Tutti i caratteri da Chr$(0) a Chr$(129) sono correttamente riconosciuti e
ordinati, ma non isuccessivi.
Se si prendono in  considerazione due caratteri ad es. Chr$(140) e
Chr$(130), si scopre che VB (o Windows) crede che Chr$(140) sia più basso di
Chr$(130).
prova:
StrComp(Chr$(140), Chr$(130), vbBinaryCompare) = -1
MA NON DOVREBBE ESSERE =1 ??????
Dove sta l'errore?
Ciao.


Posto che VB usa internamente l'Unicode i precedenti valori sono in byte
chr$(140)= 82   1
chr$(130) = 26  32
Francamente non so dirti come si determini il "maggiore" tra questi, però se
si utilizza chrw$(x) al posto di chr$(x) si ottengono i seguenti valori
chrw$(140) = 140    0
chrw$(130) = 130    0
e di conseguenza StrComp(ChrW$(140), ChrW$(130), vbBinaryCompare) = 1
Ciao Bruno

>
In effetti, in Unicode il codice carattere del codice carattere 140 (scusate
il gioco di parole) si ricava utilizzando chrW$ e ascw$.
In pratica
AscW(ChrW$(140)) = 140
AscW(ChrW$(130)) = 130
e quindi StrComp(ChrW$(140), ChrW$(130), vbBinaryCompare) è correttamente
uguale a 1
mentre posto che:
AscW(Chr$(140)) = 338
AscW(Chr$(130)) = 8218
risulterà StrComp(chr$(140), chr$(130), vbBynaryCompare)=-1
Bisognerà abituarci ad aggiungere la W nelle funzioni.
Ciao Bruno

 Bisognerà abituarci ad aggiungere la W nelle funzioni.
Visto allora che non sono rincoglionito ancora del tutto ?
^____________^     (solo al 78%. NdM)
Anche stavolta ho fatto centro  (sì, lo ammetto....ok, l'ho sparata a caso
anche stavolta ^_____^ )
Zeross

anche stavolta ^_____^ )
E chi ti ha mai detto niente? :)
Perň rimane il problema di questa strana convenzione
AscW(Chr$(140)) = 338
AscW(Chr$(130)) = 8218
Ok, la prendo per quello che č, ma non mi sembra molto logico.
Ciao.

 wrote in message 7e7ves$msr$1...@nslave1.tin.it...

Forget "logic" when you're talking about Microsoft !
^_______^
Zeross

^_______^
Yeah, I forgot this highest principle :)
See u!

Mi sembra di aver capito che la comparazione di stringhe non è più tanto
semplice.
Il mio problema originario era di confrontare delle stringhe di 70 caratteri
che mi arrivano tramita la porta seriale da delle apparecchiature; quindi io
eseguo la seguente istruzione:
X=Comp(StringaNuova, StringaPrecedente,vbBinaryCompare)
Esiste un semplice metodo per ottenere un risultato sicuro senza dover
convertire le stringhe in arrivo?
Vi ringrazio tutti.
Giuseppe