Newsgroup: it.comp.lang.visual-basic
Titolo: help procedura

salve, sono un niubbo di vb6 e sto creando un "gioco di ruolo" per
imparare ad usare vb. ho un problema in una mia procedura che non
riesco a risolvere...
innanzitutto punti_stat e' generale e forza e' globale, al momendo in
cui si clicca su bot_for_su forza = 0 e punti_stat e' un numero random
positivo
il codice e' il seguente:
Private Sub incremento_stat(ByRef stat As Integer, ByRef
punti_disponibili As Integer)
If (punti_disponibili > 0) Then
    Select Case stat
    Case 0 To 11:
    stat = stat + 1
    punti_disponibili = punti_disponibili - 1
    Case 12 To 14:
    stat = stat + 1
    punti_disponibili = punti_disponibili - 2
    Case 15 To 16:
    stat = stat + 1
    punti_disponibili = punti_disponibili - 3
    Case 17:
    stat = stat + 1
    punti_disponibili = punti_disponibili - 4
    End Select
Lab_stat.Caption = Str$(punti_disponibili)
End If
End Sub
Private Sub bot_for_su_Click()
Call incremento_stat(forza, punti_stat)
Lab_for2.Caption = Str$(forza)
End Sub
l errore che mi da e' byref argument type mismatch :D
se potete anche spiegarmi l errore vi ringrazio cosi non commetto piu'
lo stesso errore :P
thx mille!

 l errore che mi da e' byref argument type mismatch :D
Sembrarebbe che o stat o punti_disponibili non siano integer..hai provato
senza il ByRef davanti?
Al3x
ps:
trovo che i pulsanti siano più chiari se iniziano con cmb invece di bot
secondo la notazione polacca....o no?

...

forza e punti_stat sono integer (sono i valori passati alla procedura)
e' questo il problema!
anche senza il byref non funziona
sono nuovo nel vb :D non sapevo di questa notazione polacca. thx
useroì cmb

 l'errore che mi da e' byref argument type mismatch
L'errore significa che hai passato un parametro di un tipo diverso da quello
che la tua Sub si aspettava.
Nello specifico potrebbe darsi che "forza", oppure "punti_stat" siano stati
dichiarati come Long, e non come Integer.
Il problema c'è solo nel caso di parametri ByRef (che è peraltro il
comportamento di default dei parametri in VB). ByRef significa infatti che
le variabili vengono passate come "riferimento" e possono essere modificate
dalla Sub che le riceve. Per questo è necessario che quello che gli viene
passato sia dello stesso tipo di quello che la Sub si aspetta.
Se non dovessi modificare le variabili nella Sub, potresti dichiarare i
parametri della Sub come ByVal, oppure durante la chiamata passarli tra
parentesi (ogni parametro deve essere tra parentesi, è il sistema che usa VB
per fare il Cast dei dati).
In entrambi i casi però, il dato che arriva alla Sub, anche se modificato,
non torna indietro al chiamante.
In effetti sarebbe buona norma evitare l'uso dei parametri ByRef, perchè
sono spesso causa di problemi dati appunto dalla facilità con cui il valore
può essere cambiato anche solo volendo.
Per evitere questo comportamento, dovresti però reingenierizzare il tuo
progetto.
Per esempio, immagino che ogni personaggio abbia delle caratteristiche
numeriche; a questo punto perchè non creare un Tipo che le contenga tutte?
Es (da inserire in un modulo):
Option Explicit
Public Enum eCaratteristiche
  EC_PuntiDisponibili = 0
  EC_Forza
  EC_Destrezza
  EC_UltimaCaratteristica
End Enum
' Ne mancherebbero evidentemente altri, che però puoi aggiungere tu
' Le caratteristiche finiscono in un array dentro una tua struttura,
' e per recuperarne il contenuto usi la Enum
Public Type tDatiPersonaggio
    Nome As String
    Caratteristica(EC_UltimaCaratteristica) As Long
End Type
' Ti presento il personaggio vero e proprio ;-)
Dim Personaggio As tDatiPersonaggio
' In realtà sarebbe meglio fosse un array, che conterrà tutti i personaggi
del tuo gioco.
'A questo punto la tua Sub diventa una Function:
Private Function incremento_stat(ByVal IndiceCaratteristica As _
         eCaratteristiche, ByVal Stat As Integer, _
         ByRef Personaggio As tDatiPersonaggio) _
         As tDatiPersonaggio
   incremento_stat = Personaggio
   If (Personaggio.Caratteristica(EC_PuntiDisponibili) > 0) Then
       Select Case Stat
       Case 0 To 11:
         incremento_stat.Caratteristica(IndiceCaratteristica) = _
          incremento_stat.Caratteristica(IndiceCaratteristica) + 1
         incremento_stat.Caratteristica(EC_PuntiDisponibili) = _
          incremento_stat.Caratteristica(EC_PuntiDisponibili) - 1
      Case 12 To 14:
         '[Etc] ...
      End Select
   End If
End Function
' E la Function la chiami così:
Personaggio=incremento_stat(EC_Forza, punti_stat,Personaggio)
Ciao
*Roby*
P.S.
Ancora meglio sarebbe usare una classe al posto di un Type, ma se sei alle
prime armi è meglio fare un passetto per volta. :-)

...

thx per l idea! pero' il valore di forza e' un int come quello di
punti_stat, per questo non capisco il mio errore! e anche se dovessi
cambiare metodo voglio capire cosa c'e' che non funziona ^_^

 capire cosa c'e' che non funziona ^_^
Vedrai che adesso si capisce ;-)
Ciao, e se devi rispondere quota solo le parti più importanti e non tutto il
messaggio.
*Roby*

 messaggio.
sorry :) devo abituarmi a sto forum ^_^

 useroì cmb
HO SBAGLIATOOO:
è cmd per i command, cmb per le combobox

 notazione polacca. thx
L'elenco di tutte le convenzioni standard di scrittura del codice le trovi
sul Sito Comune, qui:
http://www.it-lang-vb.net/Documentazione/Varie/convenzioni.htm
Ti consiglio di studiartele ed adottarle, perché ti risparmiano diversi
grattacapi in fase di debug, e permettono a chiunque di leggere agevolmente
il tuo codice.
Ciao
*Roby*

 a chiunque di leggere agevolmente il tuo codice.
Io resto dell'idea che sia un *pessimo* modo di scrivere codice,
e che oltretutto non lo rende affatto leggibile da altri...
Ciao.
-- 
BSD is for UNIX lovers -- linux is for Windows haters.

 e che oltretutto non lo rende affatto leggibile da altri...
Allora scrivi il tuo controdocumento di specifiche, cosě possiamo decidere
quale dei due sistemi č meglio.
Ciao
*Roby*

 possiamo decidere quale dei due sistemi č meglio.
news:Nvbx9.80597$
TD1.3...@news2.tin.it


 news:Nvbx9.80597$
TD1.3...@news2.tin.it
Non ho capito in quale NG si svolgesse la conversazione (se puoi per favore
la prossima volta posta un URL di Google, perché magari non tutti possono
accedere ai NG di Tin.it), ma per VB il tuo discorso non vale.
VB è pieno di globali. Sono globali le costanti di sistema, sono globali le
form, e sono globali (a livello di form) tutti i controlli.
Spero concorderai con me che leggere: lblDescrizione.Caption sia più
parlante che non leggere descrizione.caption, o che leggere frmMain.refresh
sia più chiaro che non leggere Main.refresh.
D'altra parte anche l'uso della notazione polacca per le variabili a mio
parere ha un grosso vantaggio: forza i nuovi programmatori ad usare la
tipizzazione.
VB in questo è spesso fuorviante perché consente di usare sempre il variant,
e alcuni documenti M$ che ricordo, ma che per fortuna sono spariti col
susseguirsi dei nuovi MSDN,  addirittura consigliavano di fare così.
NEl caso in oggetto, UltraK usava due variabili di nome "forza" e
"punti_stat". Se non ce l'avesse detto lui, tu avresti capito che si
trattava di variabili di tipo Integer?
D'altra parte che io e te la si pensi diversamente su parecchie cose è
risaputo, basta riguardare indietro le nostre precedenti conversazioni. A
partire dai commenti che io preferisco in italiano e tu in inglese. :-)
Ciao
*Roby*

 preferisco in italiano e tu in inglese. :-)
Probabilmente, anzi... sicuramente, dipende dai diversi contesti
in cui abbiamo lavorato.


 in cui abbiamo lavorato.
Su questo siamo d'accordo. Probabilmente il mio cervello è rimasto inquinato
irreversibilmente dal fatto che ho iniziato a lavorare in Basic (come diceva
tempo fa KJK::Hyperion). :-)
Ciao
*Roby*

 a lavorare in Basic (come diceva tempo fa KJK::Hyperion). :-)
Diciamo più che altro che 4-5 anni passati a dover collaborare
con persone (programmatori e non) di diverse nazionalità e
provenienti dai più svariati ambienti mi ha necessariamente
costretto a scrivere codice che fosse il più comprensibile, il
più chiaro e il più semplice possibile.
E di ciò me ne sono avvantaggiato tantissimo io stesso...


 Esatto...
Conscio che entrambi speriamo di non dover mai lavorare assieme, vado a
dormire tranquillo. :-)
Ciao
*Roby*

 assieme, vado a dormire tranquillo. :-)
Non voglio peccare di presunzione, ma sono convinto che nel giro di
pochi giorni ti adatteresti perfettamente...
D'altra parte la M$ stessa ha abbandonato la notazione polacca (e le
sue *nuove* linee guida lo dimostrano)...
Ciao.
--
BSD is for UNIX-lovers -- linux is for Windows-haters.

 sue *nuove* linee guida lo dimostrano)...
La M$ ha abbandonato VB, e le sue *nuove* linee guide lo dimostrano.
Quando non lavorerò più con VB (ma sarò io a deciderlo, e non M$), adotterò
volentieri nuove linee guida.
Ciao
*Roby*

 deciderlo, e non M$), adotterò volentieri nuove linee guida.
Non vedo cosa la nomenclatura di nomi possa o debba centrare con
il linguaggio utilizzato....
Ciao.
-- 


 polacca *può* darti (ma non è detto che ti dia);
Sono di fretta e preferisco risponderti domani, ma mi è venuta una
illuminazione approposito del nome.
In realtà si chiama notazione ungherese. Mi suonava strano da un po', però
non ci facevo caso perchè anche notazione polacca non mi era del tutto
estraneo, ma per via della notazione polacca inversa che serviva invece per
"programmare", tra l'altro, le vecchie calcolatrici HP.
Mi devo essere rincitrullito, scusa. :-)
A domani
*Roby*
P.S.
Ho ricontrollato, e deve avermi mandato in confusione Al3xI98O che per primo
ha parlato di notazione polacca nel thread.
Mi sento un po' meno citrullo ora, ma non molto meno. :-)

 C++, quindi è quasi da apprezzare maggiormente...
Rispetto (sinceramente) HPL per le sue conoscenze, persino considerando un
... certo atteggiamento "contestatore", ma quest'ultima frase mi lascia
piuttosto, anzi, molto, perplesso. Ammetto di non conoscere alcun "C", ma
solo di averne una minima idea. Non mi pare che con C si possa scrivere di
meno, nè che, proprio per quello, sia più semplice. Mi riferisco,
ovviamente, ad applicazioni che possano essere scritte, decentemente, anche
in VB.

 In realtà si chiama notazione ungherese.
Sì, hai perfettamente ragione. In effetti la RPN aveva tratto in
inganno anche me.


 possano essere scritte, decentemente, anche in VB.
Trlasciamo il C che per molti aspetti (potenza a parte) è simile
al VB...
Parliamo del C++...
Premetto che la produttività la applico all'intero ciclo di vita
del sw, quindi (tralasciando analisi e progettazione) primo
sviluppo, testing, debugging, manutenszione, estensione,
modifica, nuovo testing, ecc... 
Se prendiamo due programmatori poco esperti(dei due linguaggi) e
gli facciamo sviluppare la stessa applicazione, ma ad uno in VB
ed all'altro in C++, probabilmente la produttività del primo
sarà di un ordine di grandezza maggiore, ed anche superiore in
caso di progetti complessi. Se prendiamo due programmatori
esperti (esperti conoscitori del linguaggio che utilizzano) e
ripetiamo la stessa prova troveremo che per progetti molto
semplici la produttività del prog. VB sarà di poco maggiore, via
via che il progetto si rende complesso la produttività del prog.
C++ andrà via via aumentando (in maniera notevole), mentre
quella del prog. VB diminuirà considerevolmente. 
Per cui ci sarà un punto di complessità (in realtà molto
"basso") oltre il quale *non* converrà più sviluppare in VB.
Questo perché gli ambienti RAD come il VB rendono più semplici i
compiti semplici ma più difficili i compiti difficili. Quindi in
caso di applicazioni"serie" (= di una certa complessità)
l'esperto programmatore C++ sarà decisamente *molto* più
produttivo di un programmatore VB, che dovrà in continuazione
fare a pugni con le forti limitazioni del linguaggio (ed il sw
di una qualità decisamente superiore). 
A questo punto sorge spontanea una domanda: se il VB è così
utilizzato le cose non possono stare come detto sopra... Il
punto è che le cose *sono* come detto sopra però...(c'è sempre
un però)... per diventare esperti programmatori VB basta un
periodo di tempo molto limitato (da poche settimane a qualche
mese), per diventare esperti programmatori C++ ci vogliono anni
ed anni... A questo punto, se si considera nella produttività
anche il periodo di acquisizione delle giuste conoscenze, il
vincitore è certamente il VB...


vincitore è certamente il VB...
Come il mercato insegna, del resto.
-- 
ciao, hal

 vincitore è certamente il VB...
Beh, qui c'è un piccolo e birichino tranello. Anche con VB bisognerebbe
passare (IMHO) almeno sei mesi per scrivere le _proprie_ Sub/Functions o
Classi che dir si voglia, per crearsi "l'ambiente" desiderato, senza mai più
pensare a "cosa fa" quella cosa (dopo, ovviamente, aver verificato che lo
faccia per bene), ma limitandosi, semplicemente (per complessa che sia) a
chiamarla, anche a costo, come accade a me, di dimenticarsi della "vera"
sintassi di VB e col grande vantaggio, in caso di necessari adeguamenti, di
intervenire in un solo, unico e ben definito punto, senza minimamente mutare
la logica dell'applicativo. ;-)

 o debba centrare con il linguaggio utilizzato....
Beh, esistono linguaggi in cui la tipizzazione non ha più molto senso,
perchè le variabili sono in realtà istanze di classi (come può avvenire in
C++, se non sbaglio), o perchè si lavora spesso con il cast. In VB invece le
sapere quando stai parlando di una variabile e quando di un controllo è
vitale.
Su questo penso si sia d'accordo perchè, pur non usando la notazione
ungherese, nei tuoi esempi hai prefissato il nome di un controllo di tipo
Label con "etichetta_" (approposito, è una parola italiana o sbaglio ;-)).
Ciao
*Roby*

 la logica dell'applicativo. ;-)
Sì, certo. Anche qui vale lo stesso discorso. Crearsi un
opportuno framework in C++ è più semplice che farlo in VB, a
patto di essere esperti...


 Come il mercato insegna, del resto.
Esattamente... un mercato che può lesinare sulla qualità ma ha
bisogno che tutto sia pronto per ieri...


 (approposito, è una parola italiana o sbaglio ;-)).
L'avevo messa in italiano apposta per te... ;-)


 L'avevo messa in italiano apposta per te... ;-)
Hehehe. Bella contromossa.
Beh, devo dire che con questo thread mi sto divertendo parecchio. :-)
Ciao
*Roby*

 (parole tue). Alla faccia della forte tipizzazione. :-)
Eh, eh... Non qualunque tipo di variabile. L'uso di Variant
impedise la forte tipizzazione, i template del C++ no.
Ti faccio un esempio cercando di "inventare" una pseudo sintassi
VB:
<code>
template<typename T> function Somma(byval a as T, byval b as T)
as T
    Somma = a + b
end function
</code>
Quando tu utilizzerai la funzione passandogli due integer
otterrai lo stesso risultato di aver scritto:
function Somma(byval a as integer, byval b as integer) as
integer
Quando passerai due long:
function Somma(byval a as long, byval b as long) as long
Quando passerai due double:
function Somma(byval a as double, byval b as double) as
double
'ecc....
In pratica il compilatore stesso si occupa di riscrivere il
codice per ogni tipo che passi alla funzione.
Ma senza perdere in tipizzazione.


 controllo di cicli termici.
Intuisco quindi l'esigenza di usare un linguaggio performante e con la
capacità di star dietro ai dati provenienti dall'esterno.
Ciao
*Roby*

 utilizzato).
Infatti il cliente, in genere, non si interessa del linguaggio utilizzato ma
del risultato finale. E sottolineo _del risultato finale_, in tutti i suoi
aspetti: stabilita', velocita', ecc.. Nel tuo caso (atipico), invece, la
"condivisione del codice" va al di fuori della tua azienda (direttamente al
cliente), la quale pretende/preferisce codice VB-only. A ognuno il suo :)
Lokar
--
Sito Comune: 
http://www.it-lang-vb.net/
Manifesto: 
http://www.it-lang-vb.net/docs/Manifesto.txt
UGIdotNET - 
http://www.ugidotnet.org

 della tua azienda
Come dicevo, anche una software house si deve porre il problema del
personale. Meglio usare un linguaggio potente per cui è più difficile
trovare personale qualificato (che va anche pagato di più), o uno general
purpose che ha una ampia base di sviluppatori con esperienza e non troppo
esosi?
Ciao
*Roby*

 dall'esterno.
Ti assicuro che le prestazioni erano l'ultimo dei nostri
problemi. La scelta è ricaduta sul C++ per motivi di qualità del
codice. Per la possibilità di creare un'architettura molto
aperta, facilmente modificabile, estendibile e testabile.
Cosa che in VB sarebbe risultata di grossa difficoltà (se non
impossibile).


 non la vedi!
Sě, č certamente molto utile, perň non č proprio la stessa
cosa. Anche solo perché il compilatore istanzia solo il codice
che utilizzi al momento in cui lo utilizzi, mentre con il wizard
te lo devi creare tu al momento.
Poi, comunque, i template non hanno un utilizzo ristretto ai
solo container generici, mentre il wizard sě...


 base di sviluppatori con esperienza e non troppo esosi?
Meglio scrivere sw di qualità in un tempo x o sw scadente in un
tempo x/4? Il mercato pare scegliere l'opzione 2,ma dubito che
si possa considerare giusta...


[CUT^CUT]
Azz ho esagerato con il taglio , cmq volevo solo dire che era da tempo che
non si rileggeva un 3ad decente come questo ! Mi fa molto piacere seguirlo |
Posso dire la mia ? ho i 2EuroCent !!
Da una carriera scolastica fondata sulla programmazione ho ereditato la
buona mentalita' di cercare di standardizzare il codice , tra il verbose e
l'ungherese quello che mi e' risultato + facile e intuitivo e' stato
l'ungherese senza dubbio,  anche se devo dire che alla fine di ungherese non
c'e' rimasto nemmeno il salamino per tutte le personalizzazioni che ha
subito , oramai ho una grammatica cosi semplificata per me che il 60% del
nome e' gia' composto , io essendo ancora ( e per molto ancora ) agli inizi
, leggo e "interpreto" codice con grammatiche diverse ma devo dire che sono
tutte comprensibili , alcune + immediate per me , altre + astruse ma cmq
quello che penso e' che si dovrebbe cercare di seduire il + possibile gli
standard (anche un mix tra verbose e ungher. ) che sia di facile
comprensione senza 1000 personalizzazioni , pensateci , il verbose e' lungo
e comprensibile ma a volte la sua lunghezza toglie spazio ai commenti che
quindi resta comprensibile al 80% , l'ungherese e' pratico ma richiede
commenti dettagliati a volte che non rende immediata la lettura ( a volte
deo andare a ritrovare i commenti nelle dichiarazioni delle  func per capire
cos'era quel s_funcCiaFBI007) quindi la eggibilita' cala al 70% , una buona
personalizzazione semplice con magari 2 righette di commento rendono una
lettura e comprensione media del 60% !
( i valori sono indicativi della mia conoscienza , cio' vuol dire che se IO
leggo un listato lo capisco a colpo d'occhio al massimo all'80% )
poi come al solito il consiglio : l'ungherese e' " standardizzato ", il
verbose usa termini standard ma a volte si lascia andare in intrecci caotici
, quindi ? ... quindi
usate i commenti a + non posso cosi siamo tutti contenti !

usate i commenti a + non posso cosi siamo tutti contenti !
Naaaa, evitiamo almeno quelle patetiche variabili che si riferiscono
ad oggetti ed hanno il prefisso "o" oppure "cls"!
Dim oSmettiamola As clsPiccoPallo
Questo la dice lunga sulla modernita' del vb e di chi lo insegna :-(
-- 
ciao, hal.euroCents += 2;

 si possa considerare giusta...
Se fai ciò che vuole il mercato, la scelta è quella giusta. La selezione
naturale imposta dalla concorrenza non dà possibilità di scelta.
Puoi proporre al cliente la scelta tra qualità e tempo, ma se lui sceglie il
tempo non puoi mica riempirlo di botte. :-)
Di solito il dialogo di fronte a richieste assurde è:
- programmatore "Lo vuoi in fretta, o fatto bene?"
- committente "Lo voglio in fretta _e_ fatto bene"
(notare però che "in fretta" sta praticamente sempre prima di "fatto bene")
Ciao
*Roby*

 fretta" sta praticamente sempre prima di"fatto bene")
Basta fargli capire che le due cose *non* vanno d'accordo...
Se lo capisce avrai sicuramente un cliente soddisfatto, se non
lo capisce diventerà il cliente INsoddisfatto di qualcun
altro...


 usate i commenti a + non posso cosi siamo tutti contenti !
I commenti vanno utilizzati solo quando servono realmente alla
comprensione del codice. Quando sono superflui sono dannosi...


 accedere ai NG di Tin.it)
Togli l'indicatore di protocollo "news:"  e hai il MSG-ID da mettere
nel campo omonimo di Google. Oppure, accodalo a questa stringa:
http://groups.google.com/groups?selm=
 in modo da ottenere:
http://groups.google.com/groups?selm=Nvbx9.80597$TD1.3...@news2.tin.it
che dovrebbe funzionare.
Un Paperino e i trucchetti di gugl.

 generici, mentre il wizard sě...
Su questo concordo pienamente, non e' mia intenzione difendere a spada
tratta VB. Non e' il caso, pero', di generalizzare: in VB molte delle
"apparenti" mancanze, sono in realta' colmabili con soluzioni "abbastanza"
eleganti o di semplice attuazione.
Il tutto e ovviamente, IMVHO.


 No, ma puoi rifiutare il lavoro.
Fai pure, il cliente te lo soffio volentieri io. :-)
Ciao
*Roby*

 nel campo omonimo di Google.
Dì la verità: hai partecipato al gruppo di sviluppo di google, eh? ;-)
Grazie
*Roby*

 Fai pure, il cliente te lo soffio volentieri io. :-)
Oh, ne abbiamo rifiutati tanti di lavori... e sempre perché ci
venivano imposte specifiche che secondo noi erano
irragionevoli e che il cliente non aveva accettato di
modificare neppure a fronte di valide motivazioni...


 irragionevoli
Io invece ho il vanto opposto. Aver sempre soddisfatto i clienti anche
quando le richieste sembravano irragionevoli.
Ciao
*Roby*

 posizione della seconda H in "Height" :-)
Emm fai 3 !
-- 
<Gigio2K>
Sito Comune
Nokia -> I.T.H.N. -> 
http://www.ithn.it/
VB -> I.C.L.VB -> 
http://www.it-lang-vb.net/

 clienti anche quando le richieste sembravano irragionevoli.
Pensa che io non lo vedo come un vanto... Ci sarà mai qualcosa
sul quale siamo d'accordo?


 seconda H in "Height" :-)
persone = persone +1
Bye, G.

 persone = persone +1
Ho la sensazione che faremmo prima a contare quelli imbroccano sempre certi
termini.
A proposito, Length cosa riguarda?
Ah, dev'essere qualcosa di Net. Scommetterei che ha lo stesso significato di
Len...
Ovviamente, porca pupattola, ci saranno mille motivazioni per cambiare la
sintassi... :-((

 sue *nuove* linee guida lo dimostrano)...
abbandono che, per altro, viene giustificato dall'esimio Balena, nel libro su VB.net, con
il fatto che l'ide di vs, al semplice passaggio del mouse, visualizza la dichiarazione di
una variabile....
Insomma, saremmo non solo su un sistema di attribuzione dei nomi specifico per un
linguaggio (cosa che tu già deprechi giustamente), ma addirittura tarata su uno specifico
ambiente di sviluppo....
In soldoni, mi sembra che in questo thread (molto interessante) questo particolare
argomento sia piuttosto "debole"
Salutoni & auguri
Sergio

 Sergio
Saluti ed auguroni
Sergio.


 sul quale siamo d'accordo?
Se vieni al prossimo meeting vedrai che qualche punto di accordo lo
troviamo. Magari sulle scelte dei cibi. :-)
Ciao
*Roby*

 accordo lo troviamo. Magari sulle scelte dei cibi. :-)
Mi sarebbe sempre piaciuto venire, ma la stagione agonistica in
MTB mi lascia molto poco tempo per permettermi simili viaggi e
mangiate...
