Newsgroup: it.comp.lang.visual-basic
Titolo: Compatibilità internazionale

Salve a tutti,
Sto scrivendo un'applicazione in VB che dovrà girare su molte macchine, con 
impostazioni internazionali molto differenti tra loro (italiano, inglese, 
usa, tedesco, ecc).
Siccome è la prima volta che mi scontro con questa problematica (la 
compatibilità con i settaggi internazionali), non è che qualcuno di voi 
gentilmente può indicarmi qualche link, o qualche suggerimento, o qualunque 
altra cosa per evitare futuri crash??
Ovvio, la virgola, il punto... il formato della data e dell'ora... la 
time()... la str()... ecc... queste lo so... ma sicuramente c'è dell'altro!
Molte funzioni, in VB, tornano risultati differenti a seconda 
dell'impostazione internazionale del sistema ospitante.
Esiste un elenco, o una faq?
Grazie a tutti, e buon proseguimento.
B. 


Beh, più che altro esiste una (corposa) documentazione...
Direi che puoi partire da qui:
"Globalization step-by-step"
http://www.microsoft.com/globaldev/getwr/steps/wrguide.mspx
Saluti
-- 
Gianluca Cannalire
Microsoft MVP/MCP - Visual Basic
http://www.visual-basic.it
http://community.visual-basic.it/gianluca
 

 
http://www.microsoft.com/globaldev/getwr/steps/wrguide.mspx
Ecco... me lo aspettavo... pensavo di aver finito... e invece....
....minimo altre due settimane di studio!!!!!  :-(((
...scherzo, dai!!
grazie 1000 per il link.
Saluti
B. 

 ....minimo altre due settimane di studio!!!!!  :-(((
2 settimane??? Cavolo, sei ottimista :)))


 2 settimane??? Cavolo, sei ottimista :)))
Cosě mi spavento di meno!! :-D
Ascolta, sicuramente tu lo sai... sto lavorando in VB6, e quando imposto il 
size di un font (ad esempio in una listview) ad un certo valore, supponiamo 
8, appena confermo con "Applica" mi viene trasformato in 8,25.
Stessa cosa per il valore 10, mi viene trasformato in 9,75.
Idem per ogni altro valore...
Che senso ha??

 Che senso ha??
la risposta la trovi in MSDN, alla voce CreateFont (in particolare, 
parametro nHeight)
http://msdn.microsoft.com/library/en-us/gdi/fontext_8fp0.asp
Anche questo articolo è interessante...
http://sigchi.org/chi95/Electronic/documnts/intpost/tst_bdy.htm
Ciao!


Minch... sei piů potente di una search msdn...
Sono sbalordito!   8-) 

 "Globalization step-by-step"
E' un manuale di massoneria o insegna a mettere a ferro e fuoco le città? :)
Ciao 

 dell'impostazione internazionale del sistema ospitante.
Guarda, prima ancora che un discorso tecnico in VB, occorre che tu 
definisca bene COSA vuoi che si adatti alla localizzazione, e COSA vuoi 
che sia invece indifferente alla localizzazione.
Quando qualcosa deve essere LOCALIZZATO, devi usare, sia in output che 
in input, solo ed esclusivamente funzioni LOCALIZZATE (CStr, CLng, 
CDbl, CCur).
Quando qualcosa deve invece essere insensibile alla localizzazione (ad 
esempio, tutti i rapporti fra VB e DB), occorre utilizzare solo ed 
esclusivamente funzioni DELOCALIZZATE (Str, Val, DateSerial, 
TimeSerial).
Il Format$ va utilizzato con raziocinio, perchè a seconda dei casi può 
avere valenza Localizzata o Delocalizzata.
E' fondamentale non mescolare mai le due cose.
Il 90% dei bug da internazionalizzazione nascono dall'avere usato un 
mix di funzioni localizzate e delocalizzate, senza rendersene conto (le 
conversioni implicite sono sempre localizzate).
Da ogni problema ti scansi utilizzando i passaggi per valore e non per 
rappresentazione, ad esempio col DateTimePicker anzichè i textbox per 
le date.
Ti consiglio di scriverti una funzioncina che partendo da una stringa 
ti restituisca un valore, ad esempio un Currency, e che sia immune 
dalle impostazioni locali dei separatori.
Evita come la peste tutte le conversioni implicite, sia in output che 
in input (che è una buona norma sempre, ma quando si internazionalizza 
diventa un obbligo).
Sei parzialmente fortunato a non avere a che fare con la localizzazione 
francese o cirillica, che presentano delle particolarità subdole.
Ciao
Alberto
-- 
A questo punto hanno trovato un muro,
un muro duro, molto molto duro,
che siamo noi.

 impostazioni locali dei separatori.
Infatti è quello che farò, per tutte le funzioni che devo usare... :-)
Ti ringrazio molto per il suggerimento, in effetti è un bel rompicapo ci sto 
perdendo la ragione, ho a che fare con degli input di date ed ore in formato 
arbitrario (dd/mm/yyyy, mm/dd/yyyy, hh:mm, hh:mm am/pm), con shift da 
calcolare "al volo" per ognuna di queste date, per trasformarle in tempo 
locale (questi timestamps infatti sono tutti espressi in GMT, mentre il 
tempo locale varia a seconda di dove sta girando l'applicazione).
Il tutto, senza perdere di vista il discorso dell'eventuale ora legale e 
solare, diversa da zona a zona, tanto per mettere la ciliegina sulla torta! 
Ed inoltre, l'applicativo dovrà girare su macchine Windows nazionalizzate in 
italiano, inglese, francese, usa, ecc., e dovrà quindi visualizzare i 
risultati nel formato utilizzato dall'utente finale.
In parole povere: se mi mettevo a studiare per fare l'aggiornamento del mio 
MCSE, mi sa che lavoravo di meno!!!!!!   :-)))))
Grazie a tutti, per la collaborazione, e per la comprensione verso di me... 
in particolar modo anche per il grande aiuto che mi avete dato due settimane 
fa, con le routine per il calcolo dei fusi orari e delle ore legali/solari 
nelle varie zone, almeno quella adesso funziona perfettamente!
:-/ sto passando le notti in bianco, cazz...
Bye
B. 

 città? :)
ROTFL
