Visualizza post

Questa sezione ti permette di visualizzare tutti i post inviati da questo utente. N.B: puoi vedere solo i post relativi alle aree dove hai l'accesso.


Topics - md9327

Pagine: 1 [2] 3
16
Domande tecniche / Modifica ordine parametri nella creazione degli oggetti
« il: 23 Settembre 2010, 15:16:07 »
Spulciando un pò di documentazione, sul sito ufficiale, ho fatto una bella scoperta, che sconvolge abbastanza la conversione dei progetti dalla 2 alle 3.

Nel nuovo Gambas3, a quanto pare, l'ordine con cui devono essere passati i parametri, richiesti e facoltativi, per la creazione di un oggetto, grafico e non, in pratica la chiamata del metodo nascosto _new(), è stata completamente stravolta.

Nella versione Gambas2, i parametri venivano letti partendo da destra verso sinistra, ovvero gli ultimi parametri, quelli più a destra, servivano all'oggetto più alto nella catena di inerenze. In pratica, se si creava un controllo, ad esempio una TextBox, perdonalizzato in modo da accettare altre impostazioni a livello di creazione, i parametri necessari, ovvero il container parent e le altre personale implementazioni seguivano il seguente ordine:

_new( parametro1, parametro2, ..., Container )

quindi il contenitore, opzionale o meno, risultava l'ultimo della lista.

Nella versione Gambas3, questa logica viene completamente stravolta, e non parlo di una semplice inversione di ordinamento, bensì di uno stravolgimento che tiene conto anche de un parametro è opzionale o obbligatorio.
Secondo questa nuova logica, le regole da seguire ora sono le seguenti:

1) i parametri obbligatori seguono la logica antica, ovvero l'ultimo parametro è quello relativo all'oggetto parent più in alto della catena
2) i parametri opzionali seguono anch'essi la stessa logica

questo però separando completamente i due blocchi in parti distinte, ognuna con il proprio ordine.
In definitiva avremo un misto composto da due blocchi: parametri obbligatori, parametri opzionali.

Spero di aver spiegato bene questa nuova implementazione che, a mio avviso, complica di molto eventuali conversioni di vecchi progetti. Inoltre, vista la divisione in due blocchi distinti, è necessario fare attenzione anche ai due ordinamenti.

...lungi da me commentare tale modifica...

17
Programmazione / Creazione componenti Gambas
« il: 21 Settembre 2010, 13:13:48 »
Inizio qui una sorta di discussione, circa la creazione e l'uso dei componenti in Gambas. Questo fino a che non sarà raggiunto un tale volume che obbligarà in qualche modo a farne una voce nel menu principale del forum.

Per iniziare, credo sia d'obbligo indicare allo stato attuale il nostro caro Milio, come massimo esperto nel forum, nella creazione di nuovi componenti.
Spero non me voglia, ma ha già e più volte dimostrato di saper costruire un componente, utilizzando le funzionalità offerte da Gambas.

A milio, appunto, inizio a porre una prima serie di domande:

1) cos'è un componente (utile per i neofiti)
2) differenze tra Gambas2 e Gambas3
3) come si fà ad aggiungere nuovi componenti nell'area Tool dell'Ide di Gambas.


18
Domande tecniche (Gambas 2) / Velocità grafica
« il: 18 Settembre 2010, 15:59:59 »
Dato che allo stato attuale, con Gambas2, non sono riuscito a trovare sistemi per velocizzare il disegno su una DrawingArea, pongo questo quesito, nell'eventualità che qualcuno abbia qualche idea a cui non ho pensato...

Il problema è il seguente:

sò che ormai parlo solo di pgDesigner, ma è proprio su questo che stò lavorando per poter ottimizzare il disegno dei diagrammi.
In pratica ho un pannello, una DrawingArea, di dimensioni variabili, e comunque non inferiori a 500x500 pixel (può arrivare a dimensioni ragguardevoli, es. 16000x16000, su cui vengono disegnati diversi oggetti, il cui contenuto varia a seconda di alcune impostazioni.
Dalle prove che ho fatto, i tempi di elaborazione e disegno di questi oggetti, anche se di numero ragguardevole, sono calcolabili in millisecondi, per cui apprezzabili. Il problema nasce dalla necessità di implementare un sistema di zooming, in modo che il diagramma venga ridimensionato, ivi gli oggetti che contiene, rispetto ad una impostazione, che può variare dal 25% fino al 400%.
Onde evitare di ridimensionare l'area se non viene modificata rispetto alle dimensioni originali (100%), effettuo una semplice copia dell'immagine che, tra le altre cose tengo bufferizzata in un'oggetto Picture in memoria. Questa copia è praticamente indolore, nel senso che, nonostante le dimensioni del diagramma, è all'ordine anch'essa di pochi millisecondi.
Il problema si presenta, quando la procedura si accorge che c'è da effettuare un stretching, ovvero un ridimensionamento dell'immagine, rispetto alle impostazioni di base, ovvero se viene richiesto di ridurle o aumentarle secondo una determinata percentuale. In questo caso sono stato obbligato ad usare il metodo Stretch dell'oggetto Image, passandogli i giusti parametri di altezza e larghezza.
Dai test che ho effettuato, dopo aver ottimizzato tutto il codice che la procedura utilizza per il disegno, sono arrivato al punto in cui oltre non posso andare, ovvero devo usare una funzione (Stretch) di cui non sò assolutamente nulla.
I test, dicevo, mi hanno dimostrato che i tempi che alle funzioni, in particolare Image.Copy() e Image.Stretch(), occorrenti per completare il processo, sono tangibili, nell'ordine di secondi o decine di secondi, il che vuol dire che l'utente che guarda il diagramma, deve attendere molto prima di vederne i risultati, e devo dire che a me che l'ho costruito dà molto fastidio.

Tanto per fornire alcuni numeri, di seguito il debug di ogni singola operazione, tenendo presente che l'esempio di seguito mostrato si riferisce ad una elaborazione di stretching al 400%, con un diagramma finale di dimensioni pari a 12736x13476 pixel (un bel numero...):

Citazione
Dimensioni finali DrawingArea: 12736,13476
Percentuale di zoom applicata: 400%
Disegno di tutti gli oggetti: Start: [09/18/2010 15:15:24.679] Tempo (secondi):

Semplice copia dell'immagine bufferizzata: Start: [09/18/2010 15:15:24.680] Tempo (secondi):

Stretching dell'immagine: Start: [09/18/2010 15:15:24.680] Tempo (secondi): [12]
Disegno del buffer sulla DrawingArea: Start: [09/18/2010 15:15:37.353] Tempo (secondi): [7]

Come si può notare, le uniche funzioni che hanno un tempo apprezzabile, sono relative allo strething e alla copia dell'immagine.
Devo anche dire che la cosa è proporzionale, ovvero al 200% i tempi diminuiscono della metà, e così via...
Con fattori di zoom inferiori al 100%, i tempi sono uguali a zero.

Come ho scritto, ogni singola riga del log si riferisce ad una determinata funzione dell'oggetto Picture (o Image), ovver il metodo chiamato, senza ulteriori codifiche inframmentate.

Come ultimo, faccio anche notare che il tutto ha girato sul mio pc, che ha una sk madre Asus, processore Intel QuadCore 2.5MHz, 8Gb di ram 800MHz, sk video NVidia Geforce 9300... e ho detto tutto...  :rolleyes:

Sò che qualcuno del forum ha avuto modo di giocare con la grafica in Gambas, e forse può darmi un suggerimento su modi migliori, o alternativi, per poter velocizzare il tutto...


19
Programmazione (Gambas 2) / Esempi in Gambas2
« il: 16 Settembre 2010, 18:09:01 »
Giocando e provando con Gambas2, ho creato nel tempo alcuni piccoli progettini di esempio, per testare alcune funzionalità di questo linguaggio.

Credo di far piacere a qualche neofita, mettendoli a disposizione su questo forum.

Sono piccoli progetti, la maggior parte con indirizzo su un particolare tema, facilmente leggibili e immediatamente funzionanti.

Spero che il gran gambero di quel "cesko" non abbia a che ridire sul fatto di li posto in una discussione.  ;D

[per Cesko]
Nell'eventualità, puoi spostarli dove pensi sia meglio!  :-\

20
OpenBar / Perché odio i Framework
« il: 07 Settembre 2010, 11:29:21 »
Rivolto in particolare a chi ha avuto in qualche modo a che fare con i framework, in particolare quelli per Java...

Leggere questo link, fino all'ultima goccia...

http://local.joelonsoftware.com/wiki/Perch%C3%A9_odio_i_Framework

21
Programmazione (Gambas 2) / Modifica set di icone da applicazione
« il: 31 Agosto 2010, 12:42:07 »
Ci stò pensando, ma nonostante i miei tentativi, mi scontro con alcuni problemi, legati ad alcune ristrizioni di Gambas2 (almeno io le considero tali).

Vediamo se qualcuno esce fuori con una bella idea...  :-[

Il problema, come da oggetto, è il seguente:

1) ho la mia bella applicazione, composta da classi e form grafiche;
2) nel codice delle classi non grafiche, gestisco tranquillamente le immagini e le icone dell'applicazione
3) nelle form (dialogo e non) sono impostate a livello di IDE le immagini visualizzate che, ovviamente puntano ad una dir del progetto stesso.

il punto è questo: come cambiare il blocco di icone gestire da tutti gli oggetti del programma, sulla base di una scelta dell'utente, memorizzata da qualche parte?

Riguardo alla gestione dell'impostazione in sè stessa, ovviamente, non è il problema. Il problema reale è che l'intero progetto, ivi comprese le sottocartelle, viene inglobato tutto all'interno dell'eseguibile. Questo ovviamente permette di leggere il contenuto della struttura memorizzata, ma non di scriverci sopra (è un file compilato!).

Ammesso che ioimposti una serie di sottocartelle, ognuna contenente un diverso set di icone, come dire a gambas di usare l'una piuttosto che l'altra?
La cosa, ovviamente, sarebbe piuttosto semplice farla per il puro codice, ma per le form come la mettiamo, visto che puntano a path ben precise?

Ho provato anche a studiare l'oggetto Stock che dovrebbe compire un qualcosa utile allo scopo, ma invece non lo è. Inoltre ho proovato ad impostare nelle form, delle icone che puntassero a directory, magari create all'avvio dell'applicazione e popolate in base alla configurazione definita, ma l'IDE non permette di selezionare immagini al di fuori dell'ambito del progetto, ovvero la sua cartella e relative sottocartelle.

Ho anche provato a capire come funziona la selezione delle icone dagli Stock messi a disposizione da Gambas, ma ho visto che la cosa mi porta molto fuori strada.

Insomma, inizialmente avevo pensato fosse una cosa semplice, ma in effetti alcune restrizioni complicano la cosa. Ovviamente il tutto sarebbe più semplice, se le form non esisterebbero, oppure fossero create run-time, ma questa è un'ipotesi da scartare dato l'elevato numero i form.

Detto questo, e buttato nel forum questo bel dilemma, spero che qualcuno tiri fuori un'idea per risolvere.
Ovviamente, se il quesito non è chiaro, sono qui pronto per le spiegazioni.

Bye

22
Progetti degli utenti / GLibrary
« il: 18 Agosto 2010, 13:46:02 »
Pensandoci bene, ho creato un pacchetto che contiene classi e funzioni.

Il pacchetto contiene le sequenti classi:

GColor: classe colore. In gambas manca una classe del genere; esiste l'oggetto Color ma è solo un contenitore di costanti di colore.
GFifo: classe FIFO.
GGeometry: funzioni di geometria (statiche)
GSys: funzioni di sistema (statiche)
GUtil: funzioni di utilità (statiche)
GWeb: funzioni per il web (statiche)

Successivamente cercherà di aggiungere nuove cose, utilizzando questa classe, in modo da non disperdere il codice su più thread.

23
Progetti degli utenti / Classe Geometry
« il: 18 Agosto 2010, 13:14:45 »
La classe, che è contenuta nel file allegato, contiene alcune funzioni statiche geometriche.

Non descrivo i metodi perchè troppo lungo, e poi credo che basti leggere il codice per evidenziarne le funzionalità.

Ad ogni modo, quando avrò un tantino di tempo, cercherò di scrivere qualcosa di documentale.

Bye

24
Progetti degli utenti / Classe Fifo
« il: 18 Agosto 2010, 13:08:24 »
La classe seguente viene utilizzata come contenitore FIFO per qualsiasi tipo di dato.
Per FIFO si intende un contenitore in cui si inseriscono valori in modo sequenziale, che poi vengono letti (e tolti dal contenitore), partendo dal primo valore immesso.
Io lo utilizzo in pgDesigner per gestire i messaggi di log inviati dai vari moduli che poi vengono scritti su un'apposito file. La classe mi serve appunto per ricevere tutti questi messaggi e, in base ad un timer, inviarli al manager, in modo che vengano trattati indipendentemente dal processo corrente. Questo elimina i rallentamenti dovuti alla scrittura e ad eventuali altri ritardi, che potrebbero influire sulla scorrevolezza dell'applicazione.

Descrizione:

La classe Fifo non è statica, quindi è necessario creare l'oggetto. Una volta creato questo è pronto per ricevere informazioni e a fornirle, scaricandole dal suo array interno.

Metodi:

IsEmpty: ritorna TRUE se la FIFO è vuota
Pop: ritorna il prossimo elemento, e lo elimina dalla FIFO
Push: aggiunge un nuovo elemento alla FIFO
Get: ritorna il prossimo elemento, ma non lo elimina dalla FIFO
Clear: pulisce e svuota la FIFO
Create: crea un oggetto Fifo (statica)

Codice:
Codice: [Seleziona]
' Gambas class file

PRIVATE $fifo AS Variant[]

'---
' Constructor
'
PUBLIC SUB _new()
  $fifo = NEW Variant[]
END

'---
' Return true if fifo is empty
'
' @return : Boolean : Status
'
PUBLIC FUNCTION IsEmpty() AS Boolean
  RETURN ($fifo.Count = 0)
END

'---
' Removes the last element of the array and returns it. 
'
' @return : Variant : Item
'
PUBLIC FUNCTION Pop() AS Variant
  DIM item AS Variant = NULL
  IF (NOT ME.IsEmpty()) THEN 
    item = $fifo[0]
    $fifo.Remove(0)
  END IF
  RETURN item
END

'---
' Adds an element at the end of the array. 
'
' @parameter : Variant : Item
'
PUBLIC SUB Push(item AS Variant)
  $fifo.Add(item)
END

'---
' Get next element
'
' @return : Variant : Element
'
PUBLIC FUNCTION Get() AS Variant
  DIM item AS Variant = NULL
  IF (NOT ME.IsEmpty()) THEN 
    item = $fifo[0]
  END IF
  RETURN item
END

'---
' Clear fifo
'
PUBLIC SUB Clear()
  $fifo.Clear()
END

'---
' Create this object
'
STATIC PUBLIC FUNCTION Create() AS pgFifo
  DIM o AS NEW pgFifo
  RETURN o
END

Non ne ho fatto un pacchetto perchè mi è sembrato inutile.

Bye

25
Progetti degli utenti / GridViewUtil
« il: 18 Agosto 2010, 12:54:26 »
Il pacchetto in allegato contiene una sola classe GridViewUtil statica.

Descrizione:

Metodi statici:

Initialize: inizializza una GridView.
  • control (GridView): l'oggetto GridView da inizializzare.
  • rows (Integer): numero di righe contenute nella GridView.
  • header (String[]): etichette di colonna.

SetColumnSize: imposta la dimensione delle colonne
  • control (GridView): l'oggetto GridView da inizializzare.
  • column (Integer): numero colonna da ridimensionare
  • size (Variant): se Integer imposta la dimensione dal numero, se String determina la dimensione dalla stringa

ResizeColumns: ridimensiona la GridView in base al suo contenuto
  • control (GridView): l'oggetto GridView da inizializzare.

FindText: cerca la prima cella che contiene la stringa specificata
  • control (GridView): l'oggetto GridView da inizializzare.
  • text (String): stringa da ricercare
  • col (Integer): opzionale, specifica su quale delle colonne deve essere eseguita la ricerca

ScrollToText: esegue lo scroll sulla prima riga che contiene la stringa specificata
  • control (GridView): l'oggetto GridView da inizializzare.
  • text (String): stringa da ricercare
  • col (Integer): opzionale, specifica su quale delle colonne deve essere eseguita la ricerca


26
Progetti degli utenti / CSVLib
« il: 18 Agosto 2010, 12:38:13 »
Altra libreria, che avevo già postato in precedenza, ma in modo incompleto.

CSVLib server per leggere/scrivere file in formato CSV, per intenderci file di testo tabellari, con i campi separati da un carattere (li legge anche Excel).

Descrizione:

Fondamentalmente sono presenti due classi:

CSVReader: lettura file CSV.
CSVWriter: scrittura file CSV.

Dato che le due classi sono relativamente semplici, il modulo di test allegato al pacchetto spiega da solo.

Sono comunque a disposizione per eventuali chiarimenti.

Ciao

27
Progetti degli utenti / RTFLib
« il: 18 Agosto 2010, 11:57:25 »
Continuando la pubblicazione di codice Gambas2, in allegato la libreria RFTLib, utile per la creazione di file RTF.

Nel pacchetto ho inserito un modulo di test per la sola scrittura.
Dato che la libreria è un porting di alcuni sorgenti C ricercati in rete, non di mia creazione, e dato che al momento ho utilizzato la libreria solo per scrivere file RTF e non leggerli, ho poco da scrivere. Le classi sono abbastanza complesse, e forse l'esempio allegato conta più di mille parole.

Ad ogni modo, sono disponibile per eventuali chiarimenti.

Descrizione:

Come detto, la libreria è abbastanza complessa, ma al momento non ho potuto migliorarla, nè tantomento documentarla, perchè mi è servita per determinati scopi, e non ho approfondito la cosa. Ad ogni modo, di seguito sono elencate le classi, e una descrizione sommaria della loro funzione.

RTFColor: struttura colori RTF. Usata per la tabella dei colori. Valori uguali a -1 sono usati per utilizzare il colore di default. Il colore predefinito è dipendente dal writer.

RTFFont: struttura font RTF. Usata per la tabella dei font.

RTFKey:

RTFReader: lettore RTF.

RTFStatic: tabella codici RTF.

RTFStyle: struttura stili RTF. Usata per la tabella degli stili.

RTFStyleElt: struttura stili RTF. Usata per la tabella degli stili.

RTFWriter: scrittore RTF.


28
Progetti degli utenti / XMLLib & INILib
« il: 17 Agosto 2010, 15:45:05 »
Diciamo che in questi ultimi mi sono un pò perso, ma tanto il buon "cesko" mi indirizzerà per la giusta strada... (attento però...  :evil: )

Comunque, per il momento ne parlo qui...

Con pgDesigner (ma sempre di stò programma parli???) avevo, e stò ancora implementando, creato una serie di librerie utili, che mi sono deciso di estrapolare e creare una serie di pacchetti distinti, in modo da renderli disponibili a tutti.

In questo frangente, ho dato un ripulita ad un paio di blocchi (ho tolto alcuni agganci ad altre librerie dell'applicazione), rendendoli più generalizzati:

XMLLib: una gestione di file xml che si basa sulle classi XMLReader/XMLWriter per scrivere, ma gestisce completamente e in modo, a mio avviso, più semplice le informazioni e i dati componenti una struttura XML, con la possibilità di leggere/scrivere file di tale formato, e ovviando ad alcuni problemi da me riscontrati nelle due classi Gambas (pure segnalati).

INILib: classe simile alla precedente, ma che sostituisce l'oggetto Setting di Gambas, eliminando anche con questa alcuni problemi riscontrati anche con questa libreria.

I due pacchetti sono composti ciascuno di tre classi: Document, Element e Attribute.
Per rendere le due librerie molto simili, ho cercato di gestire le cose con le stesse identiche nomenclature, come pure i parametri, in mod che possano essere facilmente essere rese intercambiabili (o quasi). Dato che alla fine le due librerie svolgono più o meno le stesse cose, mi è anche parso più che giusto farlo.

Descrizione:

Document: questa è la classe base del pacchetto, e tutto parte da questo oggetto, comprese la lettura e la creazione da/verso il file di destinazione. Fondamentalmente questa crea uan struttura dati di base, vuota, sui aggiungere di volta in volta i vari Elementi.

Element: sia per i file xml che per la struttura tipo file INI windoz, esiste il concetto di elemento, o gruppo, su cui vengono associati vari attributi. Nel caso di un file INI, la struttura può contenere solo due livelli, ovvero un gruppo a cui sono collegati un certo numero di attributi figli, come ad esempio:
Codice: [Seleziona]
...
[gruppo]
attributo=valore
...
questo, ovviamente all'infinito, ma solo e sempre con una struttura bilivello. Nel caso dell'XML, la cosa può assumere profondità più accentuate, oltre al fatto che ad un elemento possono essere associati, oltre ad attributi, anche ulteriori sottoelementi, con ulteriori sottoattributi, e così via, fino a raggiungere complessità maggiori.
Codice: [Seleziona]
<root>
  <elemento1 attributo1="">
    ...
    <elemento2>valore</elemento2>
    ...
  </elemento1>
  ...
</root>

Attribute: come nell'esempio precedente, questo è l'oggetto che rappresenta un singolo attributo di un preciso elemento della struttura. Nei file INI rappresenta una determinata proprietà di un determinato gruppo; in XML... bè, l'esempio credo dimostri la cosa...

Per il momento le due librerie le appoggio in questo thread. Poi si deciderà se metterle in posti più idonei.

Bye

29
L'angolo dell'artista / Banner e icone per pgDesigner2
« il: 17 Agosto 2010, 13:37:17 »
Seguito il consiglio "purtroppo" di cesko, eccomi qua a fare la mia richiesta, piccina picciò... :-)

Una mia applicazione, in particolare pgDesigner, avrebbe la necessità di una ristrutturazione a livello di icone e, forse, del logo.

Inizialmente, e anche successivamente, ho provato a creare un set di icone per la versione 1.x, ma la cosa, oltre a portare via del tempo prezioso alla programmazione, non era andata molto bene. Alla fine ho racimolato le icone presenti nel sistema e in giro per la rete.

Da qualche tempo stò lavorando sulla versione 2 del programma, e al momento stò usando il set di icone della versione precedente. Mi piacerebbe molto creare un set personalizzato, e abbastanza serio per questa nuova. Al momento anche il logo è rimasto pressochè simile, con una leggera piccola variante, per identificare la nuova versione, e che ho costruito utilizzando i template di Gimp.

Dato il numero abbastanza elevato di icone, se qualcuno è disposto a lavorarci sopra sarebbe cosa molto gradita e renderebbe l'applicazione graficamente migliore.

pgDesigner, per chi non lo conosce, è distribuito sotto licenca GPL sul sito sourceforge.net, ma la versione 2 è ancora sotto repository SVN, che si può scaricare a livello di sorgenti, tramite il comando:

Codice: [Seleziona]
svn co https://pgdesigner.svn.sourceforge.net/svnroot/pgdesigner/pgdesigner/branches/2.0-alpha pgdesigner

Resto a disposizione per qualsiasi chiarimento.

Ciao e grazie


30
Progetti degli utenti / EditColumnView - ColumnView editabile
« il: 15 Agosto 2010, 17:02:41 »
In realtà ho aperto questa discussione non per una ricerca di aiuto, ma per fornire qualche elemento di aiuto.

In allegato invio una form, in cui ho utilizzato l'oggetto ColumnView, giocando con la quale ho cercato di rendere la classe in qualche modo editabile, nel senso che può essere, ad esempio, usata per modificare un file di configurazione (come nel mio caso), o per altre utili cose all'interno di una qualsiasi applicazione.

L'oggetto ColumnView è un elemento molto comune in altri linguaggi, anche se magari non si chiama allo stesso modo, ma che unisce due oggetti grafici di base: TreeView e GridView.
Nell'esempio in allegato, ho aggiunto la gestiore di coppie di dati [chiave, valore], con la possibilità di modificare il valore, tenendo presente il tipo, ad es.: Text=stringhe, Check=boolean, Combo=combobox per lista di stringhe, Color=selezione colore, Font=selezione font, Number=inserimento valori numerici, e così via.

L'esempio non è ancora completo, perchè aperto a qualsiasi implementazione, modifiche e miglioramenti.
Ho provato questa cosa, per avere qualche idea migliorativa per pgDesigner, che stò valutando, e così è uscita questa cosa in questi due giorni.

Se a qualcuno può interessare, l'esempio è libero e utilizzabile in qualsiasi modo. Spero solo che qualsivoglia aggiornamento o idea sia in qualche modo pubblicata in questo forum e, per pulizia, in questa discussione.

Se poi si riesce a farne un modulo generalizzato, meglio! Cercheremo di integrarlo come progetto vero e proprio e, magari, segnalarlo al gruppo di sviluppo di Gambas.

Ricordo che l'esempio è stato creato in Gambas2!

Bye, e spero che questa discussione si allunghi...

P.S.: sò che è ferragosto, ma questo è anche un modo per rilassarmi... :-)

Pagine: 1 [2] 3