Newsgroup: it.comp.lang.visual-basic
Titolo: [!][3] Windows XP e funzione CCur grave bug??

provate a valutare nell'ide di visual basic sotto XP un'espressione del
tipo:
CCur("n,mmmmmmmmmmmmmm")
dove n è un numero intero compreso tra 0 e 9 e gli m possono essere numeri
interi qualisiasi (escluso lo 0 per l'ultima cifra)
Scoprirete con raccapriccio che in "molte" versioni di XP la funzione
restituirà 0 mentre in altre funzionerà alla perfezione anche con molte
altre cifre dopo la virgola! :-(
Scoprirete anche che dove si presenta il problema levando la quattordicesima
cifra decimale tutto tornerà alla "normalità"!
La cosa non si verifica in nessun altro sistema operativo (da win9x a win
NT2000)! :-)
E solo con alcune versioni di XP (stesso VB stesso Service Pack): su alcune
il bug sparisce deselezionado il riferimento a MS Data Enviroment, su altre
il problema persiste anche creando un nuovo progetto senza nessun
riferimento agiuntivo.
Il problema si presenta anche nel compilato! :(
(Ma vb per fare i calcoli si appoggia su qualche libreria del sistema
operativo???)
Pronti per la "New eXPerience"??? :-(
PS:
Sembrerebbe che il problema si presenti in particolare sulle versioni di
Windows XP sulle quali sono installati gli aggiornamenti di windows update
(non posso esserne certo dato che sopra ci sono installati altri programmi).

 provate a valutare nell'ide di visual basic sotto XP un'espressione del
cut
lungi da me mettere in dubbio....ma sei sicuro al 101% che l'unica cosa che
cambia sia solo XP????e poi quale XP???....non c'è qualche casino con le
dll?...non è che è settato qualcosa che so dll in italiano su xp in
inglese?o viceversa o qualche disinstallazione
Io ho provato con
XP professional italiano
Office XP inglese
Un sacco di programmi installati
Tutto gli update di windows XP installati.....
e
MsgBox Str(CCur(1.12345678912346))
mi restituisce
1.1235...come mi sembra giusto!
:-)
...sarò fortunato ma l'XPrience a me piace!...incrocio i diti (le dita per i
non toscani)..dopo vari maltrattamenti incredibili XP prof regge!!!
;-)


La butto li'...
Verifica che nelle impostazioni internazionali del pannello di controllo
il separatore decimale sia il "." (punto) e quello di raggruppamento la
"," (virgola).
Lokar

 non toscani)..dopo vari maltrattamenti incredibili XP prof regge!!!
Quando meno te l'aspetti devi però andare a metere una pezza a 1900+ ccur
sparsi per il programma! :-(
Ciao

 "," (virgola).
In quel caso il risultato dovrebbe essere un numero molto grande... cmq il
problema si verifica solo per valori compresi tra 1 e 9 con 14 o + cifre
decimali... per tutti gli altri valori la funzione si comporta regolarmente!
Non č il separatore purtroppo! :-(

 di simile saprai dove sbattere la testa! :-(
CUT
è vero...ma non pretendiamo troppo dalle abbreviazioni.... :-)
è un problema secondo me di conversione dei tipi....probabilmente va in tilt
perchè implicitamente fa troppe cose...non è che ha un athlon il cliente che
denuncia il bug???
cmq
a fare così:
Option Explicit
Dim a As Single
Private Sub Command1_Click()
a = CSng("8,33333333333333")
MsgBox (CCur(a))
a = CSng("10,33333333333333")
MsgBox (CCur(a))
a = CSng("8,3333333333333")
MsgBox (CCur(a))
End Sub
a me torna tutto a posto!
ciauz!

Non so se puo' esserti d'aiuto la mia esperienza, pero' mi si presenta lo
stesso problema che hai tu.
La configurazione e':
WinXP-32 Pro
Athlon 800
128Mb RAM
piu' una marea di altra roba tra hw e sw (comprese tutte le
windowsupdate)...
Ho notato, tra l'altro, che si verifica effettivamente SOLO nelle condizioni
descritte da te: una cifra prima della virgola e quattordici dopo
(ovviamente tranne con l'ultima pari a 0, altrimenti _credo_ faccia un
arrotondamento e passa di nuovo a tredici cifre, per cui il problema non si
verifica...).
Se per caso trovassi soluzione al problema ti pregherei di farmelo sapere!
:)
Ciao,
- SonicBoom -

a me torna tutto a posto!
Uhm anch'io avevo risolto con un cdouble in primis; poi arrotondando
solo se necessario e solo se sotto WinXP la cifra nella stringa! 
Il fatto è che non si può nemmeno fare più affidamento sulle funzioni
di base del VB! Funzioni che hanno funzionato per anni dal VB4 fino al
VB6 senza dare nessun problema con Win9x,ME,NT,NT2K! 
A mio parere non dovrebbero mutare il loro comportamento a seconda
dell'OS! :-(
-- 
Visita il sito comune del NG: 
http://www.it-lang-vb.net
Visit: 
http://www.hardwaretips.com

dell'OS! :-(
Premesso che sono d'accordo su quanto hai scritto,
non ho mai capito l' effettiva utilita' del tipo Currency.
Tra l' altro, e' stato dichiarato obsoleto da Microsoft.
Nota cosa scrivono:
<citazione>
Visual Basic 6.0
(...)
You use the Currency data type for calculations involving money and for fixed-point calculations.
(...)
Visual Basic .NET
The Deftype statements are not supported in Visual Basic .NET. Nor is the Currency data type. 
Instead, use the new Decimal data type, which can handle more digits on both sides of 
the decimal point, for all money variables and calculations. 
Decimal is also directly supported by the common language runtime.
</citazione>
Devo dire che il Decimal mi ha sempre funzionato bene, principalmente laddove
mi serviva evitare certi problemucci del Double.
-- 
ciao, hal

mi serviva evitare certi problemucci del Double.
Purtroppo in un software di contabilità, e anche in un dichiarativo
(come quello a cui stò lavorando adesso) ma meno, il currency viene
utilizzato ovunque: decimal alla M$ l'hanno implementato solamente per
la contabilità di padron Guglielmo Cancelli dato che non bastavano le
cifre! ;o)


 provate a valutare nell'ide di visual basic sotto XP un'espressione del
Scusa lord e...ma se currency accetta solo 4 cifre dopo la virgola perchè ti
ostini a passargliene 14....???
Arrotonda e passa le 4 cifre canoniche(che poi con l'euro solo in casi
particolarissimi, che comunque in una contabilità ci possono essere, ce ne
vuole + di 2)
Il fatto di questo bug....probabilmente ce ne sono tantissimi altri....ma si
deve cercare di passare oltre no? io ho sempre usato Double(ma anche
single...raggela!)....sarò stato bravo (non credo)...fortunato
(neanche)...sono stato attento (questo forse si)....ma i conti mi son sempre
tornati!
Io credo che dipenda da office CCur fa parte dei VBA...se sopra codesta roba
buggata....installi Office 2000 che mette il suo VBA si risolve?
Se no probailmente dipende dalla rappresentazione dei numeri in memoria...ci
sta che l'XP faccia qualcosa di strano con qualche puntatore
Ciao Lord!
:-)

 sta che l'XP faccia qualcosa di strano con qualche puntatore
XP fa qualcosa di strano non solo con i puntatori LOL! Fortuna che l'ho già
spazzato via da molti server! ;-)
Ciao
Alessandro

 spazzato via da molti server! ;-)
CUT
prima o poi lo dovrai tenere rassegnati....o userai sempre e soltanto
win95/2000?...ora trovi solo xp...non vorrei essere monotono! :-D
Ciao!

 win95/2000?...ora trovi solo xp...non vorrei essere monotono! :-D
Ho appena ricevuto un ordine per una workstation dall'area di ricerca di
Trieste: il loro sistemista ha espressamente richiesto W2K e non ha voluto
sentir nominare XP! :-)
Cmq io non mi rassegno: per svolgere i compiti di un server, WindowsNT non è
indispensabile anzi!
Un fileserver funge benissimo con linux+samba, per non parlare di un server
web...
Il mio PDC è un server linux, gestisce autenticazione degli utenti,
permessi, roaming profiles, etc... e mi da un trasfer rate sostenuto di
6-7/mb sec (considerate le schede realtek, il cablaggio non ottimale, e il
tipo di Hard disk a me va benissimo), fa poi tra le altre cose da server di
posta (interna), news server (sempre a scopo interno), proxy server ecc...
Tutto trasparente per i client Windows! Se consideri quanto mi sarebbe
costata una soluzione basata su NT! ;-)
Come vedi non è fantascienza e le alternative in ambito server esistono
davvero! :-)
Però stiamo diventando OT! :(