Newsgroup: it.comp.lang.visual-basic
Titolo: [?] Anomalie da uguaglianza separatori...

Cos'è il giorno del groviera?
Il mio applicativo, prima di partire, verifica la coerenza di alcune cose.
Una di queste è la non uguaglianza fra il separatore interi/decimali e il
separatore fra le migliaia.
Sappiamo, dovremmo sapere, che in tali condizioni accadono cose inenarrabili
(anche fuori da VB).
Bene, mi limitavo a testare che il separatore interi/decimali non fosse
uguale al separatore fra le migliaia.
Quest'ultimo lo ricavo in modo simile a quanto segue:
    Dim stringa As String
    stringa = Format(1234.5, "#,###.#")
    Debug.Print Asc(Mid(stringa, 2, 1)) & " = " & Mid(stringa, 2, 1)
Ora, nel pannello di controllo, mettere il separatore migliaia uguale a
quello per interi/decimali (non importa il carattere, siano essi punto o
virgola, l'importante che siano uguali) e rilanciate il programmillo
sopra...

     Debug.Print Asc(Mid(stringa, 2, 1)) & " = " & Mid(stringa, 2, 1)
0=.
Mi sembra logico no?
Interessante...
MIk

 Interessante...
Seeee, da morire... <eg>

 debug, vero?
Lupo che intendi ? a me normalmente da :
"46 = ."
ora che centra questo con il controllo tra i separatori se poi controlli
solo il separatore dei decimali ?
non e' che hai sbagliato a incollare questo pezzo ?
 Debug.Print Asc(Mid(stringa, 2, 1)) & " = " & Mid(stringa, 2, 1)
-- 
<Gigio2K>
Sito Comune
Nokia -> I.T.H.N. -> 
http://www.ithn.it/
VB -> I.C.L.VB -> 
http://www.it-lang-vb.net/

  Debug.Print Asc(Mid(stringa, 2, 1)) & " = " & Mid(stringa, 2, 1)
E' tutto giusto, ma hai provato a ripetere il programma dopo aver fatto quel
che c'è scritto in fondo al mio primo post?

 debug, vero?
Il punto non l'ho messo come fine frase....era tutto scritto nel debug..
Mah...
MIk

 debug.. Mah...
Allora c'è un comportamento diverso. Io, con i separatori uguali nel
pannello, ottengo (come te) un Asc=0 e quindi un bel niente dopo il segno =
mentre nella finestra di visualizzazione delle variabili c'è il solito
quadratino per i caratteri non rappresentabili, nel nostro caso un carattere
con peso (Asc) pari a zero decimale.

 caso un carattere con peso (Asc) pari a zero decimale.
Eh, si io come separatore (decimali e migliaia) ho messo la virgola
magari cambia a seconda di cosa imposti boh...
tu che hai messo??
MIk

 tu che hai messo??
Ho provato con . e anche con ,
Ottengo un identico comportamento: quel carattere ha peso 0 e, quindi, non
viene rappresentato.

 fosse uguale al separatore fra le migliaia.
Faccio anche io come te.
Quasi.
In realtà, uso come valore 1.1 e poi 1111, faccio un replace$ della cifra 1
con vbnullstring, e guardo cosa resta.
Comunque, quando ricevo una stringa digitata, che dovrebbe contenere un
numero, la passo per una mia function che, più che altro, guarda la
posizione di punti, virgole, o altro, per cui delle impostazioni
internazionali me ne disinteresso.
Ad esempio, se l'utente scrive 1.1 o 1,1 per me è sempre 11/10.
Ma quest'ultima cosa è opinabile, a me va bene così.
ciao
Alberto

 Ma quest'ultima cosa č opinabile, a me va bene cosě.
Ok, ma ipotizziamo il numero/valore 1234.12345 che, per una questione di ...
"eleganza" riesponi formattato con separatori fra le migliaia subito dopo
l'abbandono del campo, cioč, supponiamo, "1.234,12345"
Ho messo apposta un numero con piů di 3 decimali.
Poi lo devi usare per farci dei calcoli.
Io mi baso (ovviamente con un'apposita routine di "conversione" da stringa
formattata a valore numerico) sui separatori (da pannello) diversi fra
migliaia e interi/decimali. Non ho ben capito, col tuo metodo, come fai a
interpretarne correttamente il suo effettivo valore numerico?
E se fosse "1.234" (senza alcun decimale)?

 E se fosse "1.234" (senza alcun decimale)?
1.234 per me vale sempre 1234/1000, ossia unovirgoladuetrequattro.
Da cosa nasce questo?
Beh, ovviamente da valutazioni empiriche.
Abbiamo osservato che chi inserisce i valori numerici, li prende da listini,
offerte, fatture, ordini, spesso applica sconti con calcolatrici, ecc...
Operando con aziende molto 'internazionalizzate', gli operatori sono
abituati a ricevere documentazione in inglese tanto quanto in altre lingue o
in italiano.
Quindi, a volte digitano 1.234 e a volte 1,234 , ma intendono sempre
inserire 1234/1000.
Morale, abbiamo tagliato la testa al toro: "manuale: i valori numerici
possono essere inseriti utilizzando indifferentemente la virgola o il punto
come separatore dei decimali."
Anni fa, abbiamo avuto molte (ma molte davvero) lamentele da operatori che
avevano digitato 1.234 (da noi interpretato come 1234), mentre intendevano
1,234.
Da quando utilizziamo l'escamotage della valutazione 'posizionale', nessun
cliente ha mai avuto la benchè minima lamentela.
Ciao
Alberto
-- 
Rigore è quando arbitro fischia

sopra...
Ecco ... con WinXP ...
0 =  
Ciao!

 nessun cliente ha mai avuto la benchè minima lamentela.
Ok, credo d'aver capito: Tu ammetti la digitazione del separatore fra le
migliaia, io no (ammetto, quindi, un solo segno di separazione, qualunque
esso sia, ma da intendersi come separatore int/dec). Con questa tua
"licenza", effettivamente, avrei problemi anch'io a "interpretare".
Grazie delle spiegazioni.

 0 =
Appunto! E ti sconfinfera? ;-)

 qualunque esso sia, ma da intendersi come separatore int/dec).
E' la stessa cosa.
Di fatto, il separatore più a destra vale come separatore decimali, gli
altri è come se non ci fossero.
Alla fine, otteniamo lo stesso numero.


 gli altri è come se non ci fossero.
scusate se mi intrometto :-)
e se uno è così pirla da scrivere 1.234 intendendo
milleduecentorentaquattro, come la impagliamo?
--
Salutoni
Sergio

Appunto! E ti sconfinfera? ;-)
Mi consolo pensando che in Vb.Net non succede! :-P

[*CSSoft*=
news...@cssoft2001.com
] ha scritto:

Per me (e anche per Albe) vale 1virgola234, ovvero una unità e 234 millesimi
Fermo restando che (almeno io) non ammetto alcun separatore se il campo non
ammette decimali e, se li ammette, ammetto un separatore solo, quello è un
separatore interi/decimali. Fine! ;-)


Statisticamente (verifica, se vuoi), la probabilità che con 1.234 si
intendesse 1234 è quasi nulla (oggettivamente, i separatori delle migliaia
non li mette nessuno).
Mentre la probabilità che con 1.234 si intendesse 1234/1000 è elevatissima.
Quindi, visto che l'obiettivo è fare qualcosa che 'capisca' cosa intende
l'utente, gli diciamo che comunque i separatori delle migliaia è meglio che
non li metta. Ma se copiaincolla da una e-mail un importo, ad esempio
ricevuto dall'America, devo gestirlo.
E, siccome in tutto il mondo o quasi nei documenti i decimali vengono sempre
esplicitati, voilà.
Ripeto: è una decisione non valida universalmente.
L'alternativa, è basarsi sulle impostazioni internazionali. Ma, come detto,
alla luce dei fatti è peggio.
Ciao
Alberto

 int/dec
Mai dare queste "liberta'" agli utenti/operatori, perche' (esperienza personale
di 15 anni di programmazione) vanno sempre "forzati" ad una certa regolarita'
nella logica del programma, tanto piu' se, come in questo caso, c'e' il dubbio
se il valore digitato possa essere decimale!
Se il campo e' sicuramente intero allora gli si fa fare "beep" se premono punto
o virgola, se il campo e' decimale (ad esempio se e' una valuta) allora
accettare sempre e solo il punto (che e' piu' comodo da digitare visto che si
trova sul tastierino numerico), sempre UNO solo, e se si tratta di valuta
controllare che i decimali siano solo due (obbligatori), e comunque mai la
virgola.
Solo facendo cosi' si evitano "impicci" nella programmazione, e tanti problemi
con utOnti.
-- 
Ciao!
   -DocDoc-
--- Per scrivermi: 
do...@despammed.com
Sei anche tu stanco dei messaggi spam? Usa Terminator, il programma
anti-spam italiano FREEWARE! 
http://www.sertel.net/terminator/

 problemi con utOnti.
Allo stato, io non ho impicci di questo genere con gli utenti, tranne (come
da post iniziale) le stranezze M$.