Newsgroup: it.comp.lang.visual-basic
Titolo: currency vs double

Vorrei porre al newsgorup la seguente domanda.
Quanti di voi usano i currency perchè in calcoli finanziari riescono ad
essere più precisi?
Quanti di voi invece usano i double sempre e comunque anche solo per un
discorso di standardizzazione del tipo di dato?
Io ho scelto tempo fà di usare sempre e solo long, integer e double.
Sarei curioso di sapere dai più esperti, quali sono le linee che utilizzano
per la scelta del tipo di dato.
Ho dato un'occhiata ai post vecchi su google, sono emersi i classici
problemi di precisione per i double molto grandi però non ho ben chiare
quali siano le sfighe del currency, a parte che essendo a virgola fissa se
hai più di 4 cifre decimali sei nella cacca.
Raccontate raccontate... vi ascolto.
--
"Colui che di propria iniziativa si distacca dalle regole di condotta di
questa  guerra umanitaria non può aspettarsi da noi null'altro che
ugual trattamento: condurrò questa battaglia contro chiunque, fin
quando i diritti non saranno garantiti (Adolf Hitler discorso dell'1
settembre 1939, invasione della Polonia)".

 virgola fissa se hai più di 4 cifre decimali sei nella cacca.
Puoi moltiplicare o dividere il valore per 10^x per ovviare alla virgola...
puoi utilizzare un decimal se ti servono più cifre....
hth

 eliminati! ;)
Beh, in parte è discutibile questa preclusione verso i double.
Anche nel campo finanziario (dove si pensa solamente ai Currency o ai Long),
esistono grandezze che devono assolutamente essere gestite con virgola
mobile.
Pensa solamente al caso, banalissimo, di dover calcolare quanto varrà un
qualcosa che oggi vale X, che aumenti del Y% annuo (quindi interesse
composto), dopo N anni:
Valore_Finale=X * ((1+Y%)^N)
E' evidente che usando il tipo Currency per Y (tasso di interesse), la
formula sopra riportata userebbe Currency anche per il calcolo intermedio,
con il brutto risultato di troncare cifre significative prima
dell'elevazione a potenza e della moltiplicazione per il valore iniziale.
In un caso come questo, ci sono solamente due strade: usare Double per il
tasso di interesse (soluzione in assoluto più corretta: è un valore che
servirà per calcoli matematici, non deve necessariamente essere troncato), o
forzare un CDbl all'interno della formula (se si è sicuro che il tasso è
comunque esprimibile con poche cifre decimali, funziona).
Ma per nessun motivo una formula del genere deve essere calcolata con Y di
tipo Currency senza CDbl. Su importi significativi o periodi di molti anni,
l'errore può diventare significativo.
Ciao
Alberto

 hai più di 4 cifre decimali sei nella cacca.
Per quanto ho potuto verificare, solo il limite dei 4 decimali, ma, come
dicevo, per i totali vado a 2 decimali (centesimi di euro)

 unitario, saldi contabili, etc.).
e nel codice usi sempre double oppure anche currency nei casi in cui è
possibile applicarli?
Poi una cortesa.
Qualcuno potrebbe postarmi un esempio in cui double non è preciso mentre
currency si?

 currency si?
Non ne hai visti un tot in questo NG? Ogni tanto il problema salta fuori...
Comunque cercherò...

 recordset) o vettori/matrici.
Marrano, certe cose non devi neanche dirle !!!
--
Salutoni
Sergio

 vettori/matrici.
*SIC*
Non ho parole...
Lokar
--
Sito Comune: 
http://www.it-lang-vb.net/
Manifesto: 
http://www.it-lang-vb.net/docs/Manifesto.txt
UGIdotNET - 
http://www.ugidotnet.org

 Comunque cercherň...
Si ma sono pigro....

 Infatti non ci credo...
Credici tranquillamente, non me ne vergogno. I miei progetti sul SC li hai
guardati nel codice?
Mi riprometto, comunque, di fare (con calma) un post che spieghi/giustifichi
questa mia situazione (retaggio, come dico spesso, antico)

 wrote in message
news:b3np32$1mu0c1$
1...@ID-174464.news.dfncis.de

[ora, no te la prendere! Questo discorso č semiserio!!]
Caro Lupo (mannaro!) mi ricordi i bei tempi andati, quando ancora
lavoravo col vb4 e non distinguevo un integer da un long...
...Orbene, sei in buona compagnia: piů di un grande (se non ricordo
male, in "Advanced Vb" c'era qualcuno che sosteneva i molteplici
vantaggi nell'uso dei Variant...) ha fatto una scelta simile alla tua.
Perň non ricordo davvero nessuno che gradisse l'assenza di "Option
Explicit". Sono davvero curisoso di leggere sle motivazioni che ti
spingono a tanto odio nei confronti di chi deve manutenere il tuo codice
dopo che te ne sei andato...
;-)
Cesare I.
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG


Non curioso....
molto curioso...
PS: comunque per il momento continuerò ad usare i miei bei double, poi
quando mi capiterà che un calcolo non sarà preciso, allora ci penserò.
Bye!

 vantaggi nell'uso dei Variant
ecco, vedi come sono diverse le persone: io ho trovato che quell'articolo
svalutasse il libro nel tuo complesso.....
(imho, non c'era neanche molto da svalutare, l'ho trovato parecchio bruttino)
--
Salutoni
Sergio

 Cesare I.
Vediamo se indovino:
Ha avuto in mano dei progetti provenienti da altri programmatori che non
hanno usato l'option explicit
Poi si č talmente dovuto adattare, che oramai, essendosi abituato cosě,
anche i suoi li scrive in quel modo.
Ho indovinato?

 Ho indovinato?
no, ha cominciato a programmare con il commodore 64.
io che ho cominciato con lo spectrum, che obbligava a dichiarare le variabili,
ho sempre usato l'option explicit.
Tante faccine, però è vero.
--
Salutoni
Sergio

 quando mi capiterà che un calcolo non sarà preciso, allora ci penserò.
Prevenire è meglio che curare! :P

 ha scritto nel messaggio
news:b3nql0$2du6$1...@half.spin.it...

Dipende dalla posizione del confine che separa il "prevenire" dal "fasciarsi
la testa prima del dovuto"

 io che ho cominciato con lo spectrum
Stai guadagnando dei punti...
Alberto

 Tante faccine, però è vero.
Quanti ricordi...
Io facevo le elementari......
due anni fa me lo sono ricomprato, un bello spectrum48K, quello con la
tastierina di gomma.
Quando mi alzo la mattina a volte lo guardo, là... sullo scaffale, con uno
sguardo adorazione misto malinconia.

 molti anni, l'errore può diventare significativo.
Gli arrotondamenti all'euro del fisco scongiurano tali problemi di solito
(come già detto per i miei particolari scopi il currency va benissimo): per
valutare certe grandezze con più precisione sfrutto il CDbl direttamente
nella formula.

 il CDbl direttamente nella formula.
L'arrotondamento fiscale avviene sul risultato della formula.
Il punto che facevo notare è che usando Currency, i valori vengono persi
'durante' il calcolo della formula, per cui alla fine si può arrotondare
finchè si vuole, ma oramai parte dell'informazione è persa.
Però, se usi CDbl sul valore/variabile più 'interno' della formula, sei a
posto.
Ciao
Alberto

 Stai guadagnando dei punti...
beh, me ne hai appena attribuiti tre.
--
Salutoni
Sergio

 Ho indovinato?
No (rispondo, almeno in parte, anche a Cesare), ma "gli altri" ... ero
"ancora io". Partito da una certa versione di VB (forse la 3) che non
conteneva (o io l'avevo ignorata) tale possibilità, non l'ho usata. Quando
l'ho vista ... ormai era tardi. Non la metto nemmeno nei nuovi progetti (pur
appartenenti al mio unico-grosso pacchetto), vero e male, ma ... l'abitudine
e ... la prigrizia di fare Dim...
Quanto volte ho perso qualche ora per una variabile con nome cappellato?
Tre/quattro in tutta la mia vita informatica, giuro. Anche perchè siamo usi
a testare abbastanza bene le cose che faccio, oltre alle eventuali (rare, in
tal senso) segnalazioni degli utenti che fanno cose molto particolari e
rare. Non è una difesa, semmai un'ammissione di ... pigrizia.

 dopo che te ne sei andato...
Vedi risposta a David.

 persa.
Intendevo dire che arrotondando il risultato finale all'euro perdere la 5
cifra significativa dopo la virgola nei calcoli e in generale ininfluente
(dipende ovviamente dal tipo di calcoli: in linea di massima trattandosi di
somme o moltiplicazioni l'errore non dovrebbe influire sul risultato
finale)!
L'ordine delle operazioni va comunque sempre studiato per ridurre gli errori
di arrotondamento indipendenetemente dal fatto che si utilizzino double o
currency!

 sguardo adorazione misto malinconia.
Io ai tempi lo odiavo , pero' mi piaceva il colore nero
Vic20 R0X
SPK SUX
^_____________^

 questa mia situazione (retaggio, come dico spesso, antico)
Eccomi (forse per il mio "canto del cigno", qui), copio e incollo da
WordPad, se ci sono interlinee larghe parlate voi con Bill, neh?!:
A proposito di variabili tipizzate o meno, avevo pensato di scrivere un
"trattato", ho invece deciso di essere piuttosto breve:
1) Vero che il Variant (default per ogni variabile non dichiarata o
dichiarata senza tipo esplicito) occupa (per sole cifre) 16 bytes (22 per
caratteri) in memoria invece degli 8 di un Double (massima definizione
numerica tipizzata, pari alla massima definizione di un Variant), ma,
ditemi, escludendo le eventuali globali (che io uso molto, anzi, moltissimo,
ovviamente quando utili/necessarie, non a casaccio), quante variabili usiamo
all'interno di una zona a visibilità limitata (quindi, per esempio, una Sub
o Function, ovvero un evento)? Io, volendo esagerare e pensando ai casi più
complicati, direi 5, massimo 10. Queste vengono distrutte alla "morte" della
"nicchia" che le ospita, quindi la loro maggiore occupazione, oltre che
temporanea, è certamente un'inezia rispetto a tutto il resto.
2) Certamente le Variant sono più "lente" di altre variabili tipizzate, non
v'è dubbio (non fosse altro perchè il sistema deve capire se trattarle come
cifre piuttosto che come caratteri), ma quanto pesa un'operazione
matematica/algebrica rispetto, per esempio, a un singolo accesso (anche il
più semplice) a un database? Ovvio, se stiamo scrivendo un programma che
affronta problematiche scientifiche, statistiche, grafico/trigonometriche,
etc., le istruzioni dedicate all'esecuzione dei calcoli sono assolutamente
prevalenti, ma sarebbe probabilmente poco adatto anche un linguaggio come
VB, palesemente indirizzato all'interfaccia e all'accesso a dati, molto poco
scientifico, insomma.
3) Arrotondamenti/Errori: I calcoli in virgola mobile introducono, lo
sappiamo, apparenti anaomalie (ho già espresso il mio parere in merito: il
sistema, ovvero Bill, non il programmatore, dovrebbe trattare tutto in
intero in modo da eliminare ogni tipo di "stranezza" e restituire, in modo
trasparente al programmatore, il risultato esatto in forma decimale).
Sappiamo anche che tali "errori" si accentuano all'aumentare della
precisione (altro involontario ossimoro). Bene, ma se la massima precisione
è un Double, un Variant (di pari "precisione") ci regalerà gli stessi
vantaggi e gli stessi inconvenienti di un Double al quale equivale. Rammento
un linguaggio che ho usato a lungo (Business Basic della Data General) e che
ho già citato in questi lidi. Bene, quel linguaggio non ammetteva (anzi,
ammette, perchè c'è ancora, anche tramite UBL sui PC Win e, coi miei
programmi ormai trentennali, sta funzionando anche oggi) cifre decimali, nel
modo più assoluto. Occorreva trattare tutto in intero e agire poi, in fase
di esposizione, sul numero dei decimali rappresentati. Mai un errore nei
calcoli, mai! Certo, poteva capitare che 123.45 venisse
visualizzato/stampato come 12345 o 1234.5, ma bastava agire sull'istruzione
di visualizzazione/stampa e tutto finiva lì. Il limite era di 16 cifre
complessive, non poco per programmi gestionali. Permettetemi una piccola
fuga: Quella era gente che forniva prodotti professionali, mica M$...
4) Se definisco una Sub o una Function che prevede parametri/argomenti e,
diligentemente, ne dichiaro l'esplicita tipologia dovrò, sempre e
coerentemente, passare tali parametri/argomenti con gli stessi tipi
indicati. Non voglio ipotizzare il caso di un'errata progettazione per la
quale un certo argomento venga dichiarato, per esempio, Single e poi si
scopra che debba essere Double (le mani nei capelli di chi deve modificare
tutte le dichiarazioni e conteggi degli argomenti passati nelle varie
chiamate non gliele metto certo io), ma mi limito a sottolineare le
complicazioni che il passaggio di tali argomenti comporta: non potrò passare
una Double che pure mi è servita per un calcolo che al suo interno voleva
mantenere la massima precisione, ma che alla fine ha prodotto (e lo sapevo
sin dall'inizio) un risultato tale da "stare" in un Single, dovrò prima
trasformare o appoggiare tale Double in una (magari ... un'altra) variabile
Single, perchè tale tipo la Sub/Function si aspetta. Con un Variant posso
NON dichiarare il tipo dei parametri/argomenti della S/F e passo alla stessa
qualsiasi cosa, un Variant, appunto.
5) Non Dim-tipizzo nemmeno le String. Mi limito a scrivere a="pippo".
Ovviamente non tratterò mai "a" come un numero. Non aggiungo altro.
n) Per ora non mi viene in mente altro. Ok, semmai possa averne avuto
qualcuno, mi son giocato tutti i miei pochi punti di reputazione, ma,
tant'è, sono un onesto, sono un autodidatta che non ha una virgola di
teoria, so che c'è sempre da imparare, ma, per i motivi che ho detto e forse
per altri che ora non mi vengono in mente, non mollerò i Variant. Attendo
strali e critiche. Magari anche qualche indicazione che preservi la comodità
e i risultati.
PS: Tanto tempo fa qualcuno di voi mi avrà visto scrivere a proposito di
coesistenza di DAO (per Access) e ADO (per SQL Server). Bene, l'ho fatto e
tutto sta funzionando bene. Ho un unico programma, non due versioni. Come ho
dichiarato, nello stesso Progetto/Sub/Function/Evento un recordset? Non
potendo dichiarare contemporaneamente un DAO.Recordset e un ADODB.Recordset,
l'ho dichiarato come Object e poi, nei "luoghi dedicati (solo per ADO)" l'ho
tipizzato. Mi dilungo: Nel mio codice non c'è un ... As TextBox o ... As
Form o ... As CommandButton. C'è solo ... As Object.
... vi voglio bene, non siate troppo cattivi con me ...

 Ovviamente non tratterò mai "a" come un numero. Non aggiungo altro.
Mai dire mai... :-P
Ciao.
-- 
BSD is for UNIX lovers -- linux is for Windows haters.

 Magari anche qualche indicazione che preservi la comodità e i risultati.
La vera comodità è nel far eseguire al compilatore i compiti al posto 
nostro. Se c'è la possibilità di far sì che sia lui a controllare se i
parametri passati sono del tipo giusto, invece che dover essere noi a
doverlo controllare, avremo la possibilità di dedicare maggior
attenzione ad altri dettagli. Da questo punto di vista, infatti, io non
sopporto le coversioni implicite, che riducono in parte i vantaggi di
una tipizzazione statica.


 Mai dire mai... :-P
Anche questo è vero... ma se mi capita di trattare "a" come un numero non
posso che chiedermi se davvero sto facendo il mestiere giusto... :-)

 una tipizzazione statica.
Su questo sono abbastanza d'accordo, bisogna starci attenti.

 posso che chiedermi se davvero sto facendo il mestiere giusto... :-)
Sviste, modifiche, correzioni... sono molti i motivi per cui capitano
questi errori. 
O credi che tutti i programmi soggetti a buffer overflow (il bug 
maggiormente diffuso) siano stati scritti da gente che ha sbagliato 
mestiere?


 giusto e per dedicarmi ad altri dettagli...
Ma di fatto devi pensarci, non puoi passare una stringa ad una funzione
che calcola il quadrato di un numero...
E se č vero che ci vuole poco a capire questo, č altrettanto vero che ci
vuole altrettanto poco a sbagliarsi involontariamente.
E per evitare errori di questo tipo (e scrivere codice sicuro) sei
costretto ad aggiungere controlli sul tipo (If IsNumeric(...)),
controlli inutili utilizzando la tipizzazione offerta dal linguaggio.


 Ciao.

 numero o viceversa...
Sarebbe un errore madornale se fatto cosě:
a = CalcolaQuadratoDiUnNUMERO("pippo")
ma cosě č molto piů facile da fare:
a = "pippo"
.... 20-30 righe di codice
b = CalcolaQuadratoDiUnNUMERO(a)


 contenga *tutte* le informazioni che vanno condivise.
Ehhhh??? Puoi tradurre (preferibilmente in VB6), per favore? Grazie.

 Ehhhh??? Puoi tradurre (preferibilmente in VB6), per favore? Grazie.
I membri statici sono funzioni (e dati) che appartengono alla classe e
non alla singola istanza di questa classe, ma non esistono in VB6 (in 
VB.NET
 sì).
Per il resto il concetto è molto semplice, invece di avere 5-10-50,
ecc... variabili globali (pericolose) basta creare una classe che
contenga tutte le informazioni che servono per la configurazione del
programma, ed instanziarne una copia globale, magari utilizzando il
pattern singleton, per far sì che questo oggetto sia istanziabile 
una sola volta (in VB6 occorre ricorrere ad un a-x).
In questo modo hai la possibilità di creare policy di accesso per i vari
valori (sola lettura, lettura-scrittura), per evitare modifiche
accidentali e non volute.
Quindi le variabili globali diventano semplicemente proprietà (magari in
sola lettura) di un oggetto globale di classe Configurazione, che alla
sua costruzione andrà a leggere i valori dal registro o da un file ini,
o da qualche altro tipo di file.


 o da qualche altro tipo di file.
Questo è concettualmente molto chiaro.

 Cos'č una a-x? Dillo, eddai, dillo che mi vuoi morto! ;-)
Un active-x (dll in questo caso), era solo abbreviato... :-P 


 Un active-x (dll in questo caso), era solo abbreviato... :-P
Scusate se mi intrometto ma cosi ne beneficia la sicurezza del programma ma
da come la vedo io ( non avendo mai provato ) aumenta la complessita' del
programma !
Io di solito ho un modulo generale e un modulo per ogni "gruppo di form" che
compone tutto il progetto , sulle form e' tutto "private" diciamo uso una
caterva di variabili globali + procedure e funzioni e per ora non ho avuto
nessun problema ... quale sarebbe la pericolosita' delle variabili globali ?
poi so che se se le procedure o func sono specifiche per una cosa allora gli
passo direttamente valoti tipizzati a string o double , se invece sono func
un po generiche uso i variant , faccio molto uso di "sostituisci" e la
ricerca di mztools prima di fare cambiamenti nel codice ... per il resto se
in una sessione del mio programma dovro' accedere a solo 2 variabili globali
, non vedo il motivo di caricare una intera dll Ax con 300variabili ! ^_^
PS: so curiosissimo di saperne d+ di sto singleton per vb6 che oltre a un
"wiskettino" non mi ricorda nulla ! ^____^
-- 
<Gigio2K>
Sito Comune
Nokia -> I.T.H.N. -> 
http://www.ithn.it/
VB -> I.C.L.VB -> 
http://www.it-lang-vb.net/

 , non vedo il motivo di caricare una intera dll Ax con 300variabili ! ^_^
Di fatto però le tue variabili globali (300!) ci sono tutte, in quel modulo
e quindi in memoria, anche se ne usi qualcuna per volta...

 "wiskettino" non mi ricorda nulla ! ^____^
Significa semplicemente impedire che un oggetto possa essere istanziato
più di una volta. Per esempio non ha senso che in un programma possa
esistere più di un oggetto di classe Applicazione...


 singleton (ma non è necessario farlo).
Questo mi sta benissimo ed è davvero un'ottima idea: "Assicura" l'univocità
delle globali "incapsulate" in proprietà, ne favorisce la distinzione e
riferimento grazie al nome (e non al numero) e ne impedisce la sostituzione
(se proprietà di sola lettura tranne nel punto, singolo, in cui vengono
assegnate)

 modulo e quindi in memoria, anche se ne usi qualcuna per volta...
umm umm gia' questo mi sfugge , diciamo che io uso questa tecnica , nei
moduli associati alle form ci sono solo func e sub che possono in alcuni
casi modificare le variabili globali nel "modulo comune"
quindi i cicli vita dei moduli  :
- i moduli delle form vengono caricate e scaricate automaticamente ad ogni
chiamata di una func in essa contenuta , se queste func vanno a modificare
variabili globali nel modulo generale questi e' gia' caricato e non dovrebbe
essere reistanziato di nuovo o sbaglio ?
- il modulo generale contenendo le variabili globali mi sa che resta sempre
caricato in memoria dall'inizio a fine sessione finche non scarico tutte le
form e chiudo(*)  il programma perche' contiene variabili che vengono
valorizzate sin dall'inizio della sessione.
-- 
<Gigio2K>
Sito Comune
Nokia -> I.T.H.N. -> 
http://www.ithn.it/
VB -> I.C.L.VB -> 
http://www.it-lang-vb.net/
(*) End ^_^;;

 programma possa esistere piů di un oggetto di classe Applicazione...
scusa non ho capito , cosa intendi con "oggetto di classe applicazione " ?


 valorizzate sin dall'inizio della sessione.
Esatto. E in questo senso le variabili globali del BAS occupano subito e
sempre il loro spazio.
Non vorrei aver fatto confusione con la "sezione dichiarazioni" di un form.
Quello non è un modulo, è, appunto, una sezione del form e la "globalità"
delle variabili in essa dichiarate sono "globali" solo al form, non a tutto
il progetto.

 reistanziato vero ? O_o
Sì, invece, se è in un FRM scaricato
Le tue affermazioni, IMHO, sono tutte vere se ti riferisci a un BAS

 subito e sempre il loro spazio.
come sopra , mi sta bene sia per lo spazio di memoria allocato sia per la
manuteniblita' (ripeto sono per lo + usate come flag in maggioranza )
PS: Ecco un *Vizio di scrittura* che ammetto in pubblico :
A volte avendo un modulo.bas "abbinato nella mia mente ad un form" , a volte
mi viene l'istinto di buttarci tutte le func e le sub che uso nella form
abbinata , diciamo che per un vizio al posto di lasciare delle func globali
a livello di form all'interno di form1.frm , le butto nel modulo mForm1.bas
rendendole globale a livello di programma :-/ e lasciando in form1.frm i
classici sub  Command1_click ecc e nel modulo invece chesso' una sub tipo
"ControllaInserimento()" che tengo globale anche se e' usata solo da form1
:-/


 ciò non accada nemmeno quelle rare volte...
Il fatto che pur utilizzando un metodo "non consigliato" ci sia sempre
andata bene non significa che sarà sempre così...
In fondo il non utilizzare variabili globali ci pone a riparo da molti
possibili problemi, ma quello che è più importante è che ci costa
veramente poco. Al contrari oadottare uno stile OO ci salvaguarda da
molti problemi (se affrontato in modo corretto, ovviamente), ma ha un
costo non indifferente. E lo stesso si può dire per l'utilizzo di certi
linguaggi al posto di altri. Ma, ripeto, il non utilizzare variabili
globali *costa veramente molto poco*.


 :-/
Se una Sub/Function è globale (nel senso che può essere usata anche da più
forms) è più conveniente creare dei BAS "tipizzati" per la loro funzionalità
prevalente, per esempio un modulo BAS per il trattamento dei dati, uno per i
controlli, uno per le griglie, uno per ... etc. in modo da "ordinare" il
tutto.

 scusa non ho capito , cosa intendi con "oggetto di classe applicazione " ?
Qualcosa di simile all'oggetto App di VB, una classe che contenga
funzioni e proprietà che si riferiscono all'applicazione, come
l'hInstance, il percorso del file dal quale è stata lanciata
l'applicazione, l'insieme di finestre aperte, ecc...


 _SOLO_  a form1
Il problema è che non c'è nulla che ti impedisca di utilizzarle anche al
di fuori di form1...


 l'applicazione, l'insieme di finestre aperte, ecc...
umm ok e' tutto un po + chiaro !


 veramente poco.
Ripeto, a parte la classe, ancora non ho capito come non fare uso di
qualcosa di cui ho bisogno in tutto il progetto.
Facciamo così, se ti va (sempre escludendo l'idea della classe, che mi è
chiarissima): Fammi un esempio di come poter accedere a una variabile da due
form diversi senza che la variabile stessa sia globale.

 al di fuori di form1...
Certo, sono storpiature di codice che utilizzo a modo mio , sono di fatto
utilizzabili da qualsiasi parte del programma ma in realta' vengono usate
solo in form1 se il modulo e' mForm1 ... alla fine diciamo che separo le sub
e func tra :
frm in cui rimangono solo quelle legate agli oggetti ( command1_click()
ecc.. )
e sub "legata mentalmente" con (mForm1.bas )
le sub che creo io  ( ContollaInserimento(...) )  ...
diciamo che cosi so a prescindere da vedere il codice dove si trova quella
esatta sub :
Se e' un flag e' di sicuro nel modulo.bas generale
Se e' una sub tipo "Command1_clicl()" si trova nel form1.frm
Se e' una sub di controllo di una maschera di inserimento di form1 e' di
sicuro nel modulo mForm1.bas
Se e' una procedura standard e' buttata anch'essa nel modulogenerale.bas
adesso che e' passato un annetto buono che ho passato a "codare" e seguire
ed apprendere dal Ng , lo ribadisco , ci vuole una bella pausetta e riletta
... finalmente credo che potro' inizare a farmi la famosa cartella con i
moduli generali che contiene le routine + usate tipo controllo stringhe ,
date , file , ini . registry ecc ... )


 form diversi senza che la variabile stessa sia globale.
Visto che il valore contenuto nella variabile sarà evidentemente letto
da un file o dal registro o da un db, puoi (in generale) rileggerlo più
volte.


 volte.
Ok, concettualmente ci sono, ma non sempre è applicabile: non posso leggere
ogni volta dal db qual è il codice del magazzino in uso, della ditta
contabile a cui è collegato, etc. (sono solo esempi, due su 200...), non
credi? Già le procedure sono lente...

 Se e' una procedura standard e' buttata anch'essa nel modulogenerale.bas
Quello che non capisco č perché non utilizzi delle semplici funzioni
private nel file .frm.
In questo modo sono visibili nella sola form che le deve utilizzare.


 credi? Già le procedure sono lente...
Sì, appunto, per questi casi si utilizza l'oggetto globale, in modo da
leggere i valori una sola volta.


 leggere i valori una sola volta.
Se capisci questo, non dovrai avere molta fantasia per arrivare ad
immaginare le 200 globali (perplessità di cui al punto precedente)...

 In questo modo sono visibili nella sola form che le deve utilizzare.
E' appunto un viziaccio premesso sin dall'inizio ^_^ Sto usando sto metodo
negli ultimi 2 lavori che sto facendo e devo dire che mi rimane comodo da
gestire soprattutto per gli aggiornamenti delle diverse versioni , e' solo
per pigrizia ^_^ Non sono certo il mago dell'ottimizzazione anzi ... !!!


 immaginare le 200 globali (perplessità di cui al punto precedente)...
Non sto scherzando, veramente mi trovo in difficoltà a pensare un numero
così alto di valori da condividere all'interno dell'intera applicazione.


 così alto di valori da condividere all'interno dell'intera applicazione.
Ne farò un sunto, promesso, magari aprendo un nuovo topic che possa dare
qualche idea a qualcuno che deve progettare un nuovo pacchetto.

 qualche idea a qualcuno che deve progettare un nuovo pacchetto.
A proposito, devo sviluppare un gestionale, non è che mi daresti qualche
dritta? ;-)


globali *costa veramente molto poco*.
Per quanto mi riguarda, oso dire che non riesco praticamente neache
piu' a concepirle ;-)
-- 
ciao, hal

 dritta? ;-)
Sì, volentieri:
Comincia a dimensionare un vettore a visibilità globale di almeno 200
elementi, Variant, ovviamente. :-P

 piu' a concepirle ;-)
Anche tu con una classe e le sue proprietą come consigliava HPL?
Mi sta benissimo, č solo per capire se vi sono altre strade, fermo restando
che io *qualcosa* di globale lo devo (!) avere e :-P non riesco a non
concepirlo...

 piu' a concepirle ;-)
Il fatto è che chi non ci ha dovuto sbattere la testa non se ne rende
conto. Anche perché, questo va detto, si parla sempre di *potenziali*
errori; può essere che pur utilizzando tantissimo le variabili globali,
ma con un rigore ed un'attenzione (ed una fortuna) incredibili, non si
presenti mai neppure un piccolissimo problema.


 occhio!
Non pensi che un: 
Optional file_originale_passato = "nome_file_di_default" 
sarebbe stato più comprensibile pur ottenendo lo stesso effetto?


 sarebbe stato più comprensibile pur ottenendo lo stesso effetto?
Sì, generalmente, ma quel "" per me vuol dire (e non sto scherzando)
"chiedilo all'utente", sia per l'originale che per quello di destinazione.
Non c'è un valore di default, ecco perchè prima, genericamente, ho detto
"file presi all'interno della stessa"

 riesco a non concepirlo...
Non preoccuparti , non sei solo in questa lotta ^_^;


 numero, facile da sbagliare.
Ti dico come faccio io, scusate il ritardo ma a casa sono senza internet.
Il mio sistema è molto sempplice, e onestamente, per quello che faccio io,
mi trovo molto bene.
Quando un progetto ha molte cose comuni, quindi fare una variabile globale
per ognuna sarebbe folle, idem per un'array, che poi da leggere non è il
massimo, mi comporto così.
Creo una variabile definita dall'utente che abbia come membri tutte le
informazioni "comuni", poi la dichiaro public in un modulo.
A parte che così è tutto nomignolato e non occorre sbattersi a fare delle
classi, c'è l'enorme comodità, come se fosse una classe, di avere tuto che
ti compare magicamente nell'elenco membri.
:-) e scusa se è poco!

massimo della flessibilità, ma veramente il minimo di leggibilità...
:-DDD
-- 
ciao, hal

 :-) e scusa se è poco!
Mi piace e ti ruberò l'idea.
Questo consente di tipizzare i dati evitando il consumo di un Variant anche
per un booleano, nonchè (cosa ancor più importante) di chiamare i valori per
Tipo.Nome, decisamente più leggibile che non un VETTORE(128)

 VETTORE(128)
Io ti consiglierei di creare un oggetto per le informazioni comuni renderlo
globale e passarlo per riferimento ai form necessari: tra gli altri vantaggi
di questo approccio c'è la possibilità di validare le modifiche alle
impostazioni e renderle readonly se necessario!
hth

 "file presi all'interno della stessa"
In questo caso te lo concedo :-P anche se avrei fatto in modo
differente...


:-) e scusa se è poco!
Meglio utilizzare una classe, perché  puoi rendere le proprietà in sola
lettura o, come ha suggerito qualcun altro, validare l'imput.


 po' più ostico...
T=Tabella
ESCOM=Informazioni Comuni (Database ESD00COM)
AMBIENTE=Nome Tabella
Più chiaro (e univoco) di così, ... per me ;-)

 Tipo.Nome, decisamente più leggibile che non un VETTORE(128)
Momento! Come faccio a passare una variabile dimensionata come il tipo come
argomento di una S/F che sta in un modulo di tipo CLS?
In un modulo BAS scrivo:
Type pippo_tipo
    i as integer
    s as strinf
End Type
Public pippo as pippo_tipo
Nel modulo CLS (è una DLL):
Sub s1(giovanni as pippo_tipo)    'Non gli piace
Call s1(pippo)    'Non gli piace
Nemmeno se nel CLS faccio una Dim pippo as pippo_tipo
Insomma, ho la necessità in una CLS (che diverrà una DLL) di passare
(all'interno della stessa e/o da un FRM o BAS classici esterni) l'intero
oggetto tipizzato come da Type. Soluzioni? Grazie.

 Piů chiaro (e univoco) di cosě, ... per me ;-)
Appunto... per te, ora... :-P


 oggetto tipizzato come da Type. Soluzioni? Grazie.
Usare una classe...
Tra l'altro è consigliabile *non* utilizzare mai UDT (quindi type), ma
*sempre* classi... Tranne quando richiesto dall'API.
