View Full Version : [C# 2.0] inserire stringhe in posizione {0}
RaouL_BennetH
17-06-2010, 14:56
Ciao a tutti :)
Ho una label così composta:
X:{0}-Y:{0}
Durante l'esecuzione del programma, come posso inserire i valori di X e Y
evitando di usare un banale string.Insert ?
Grazie a tutti :)
RaouL.
Ma almeno fosse
X:{0}-Y:{1}
potresti "sostituire" {0} con quello che vuoi li', e poi {1} con quello che vuoi la'...
Con varie soluzioni, dalla piu' elegante e veloce a quella piu' lenta e lunga.
RaouL_BennetH
17-06-2010, 17:35
Ma almeno fosse
X:{0}-Y:{1}
potresti "sostituire" {0} con quello che vuoi li', e poi {1} con quello che vuoi la'...
Con varie soluzioni, dalla piu' elegante e veloce a quella piu' lenta e lunga.
Ciao :)
Beh, penso che essendo una label, almeno il testo di base io possa cambiarlo senza far arrabbiare nessuno.
La strada più lenta e lunga credo di averla percorsa :D perciò mi è stato chiesto di non utilizzare un metodo string.Insert() :p
Specifico un pò più di dettagli:
la label è un oggetto di tipo StatusStripLabel che, ovviamente, fa parte di un oggetto StatusStrip.
Sul form è presente una griglia, e ho il compito di tracciare le coordinate relative a riga - colonna al passaggio del mouse sulla griglia.
Al momento la soluzione che ho implementato è questa:
int nRow = 0;
int nCol = 0;
private void kGrid_MouseMove(object sender, MouseEventArgs e)
{
DataGridView.HitTestInfo hti = kGrid.HitTest(e.X, e.Y);
if(hti.RowIndex >= 0)
{
nRow = hti.RowIndex + 1;
nCol = hti.ColumnIndex + 1;
StringBuilder sb = new StringBuilder();
sb.Append("X:");
sb.Append(nRow.ToString());
sb.Append(" - ");
sb.Append("Y:");
sb.Append(nCol.ToString());
coordStatusLabel.Text = sb.ToString();
}
}
}
tomminno
17-06-2010, 17:45
Allora direi:
string.Format("X:{0}-Y:{1}", x, y);
Allora direi:
string.Format("X:{0}-Y:{1}", x, y);
;)
RaouL_BennetH
17-06-2010, 18:13
Ok :)
Grazie come sempre per il prezioso aiuto !!
RaouL.
così è un pò meglio e eviti quelle due variabili orrende che non servono a nessuno :)
private void kGrid_MouseMove(object sender, MouseEventArgs e)
{
if (kGrid.HitTest(e.X, e.Y).RowIndex < 0) return;
coordStatusLabel.Text = string.Format("X:{0} - Y:{1}", kGrid.HitTest(e.X, e.Y).RowIndex + 1,
kGrid.HitTest(e.X, e.Y).ColumnIndex + 1);
}
lock cmpxchg8b %ebx
09-07-2010, 20:10
così è un pò meglio e eviti quelle due variabili orrende che non servono a nessuno :)
private void kGrid_MouseMove(object sender, MouseEventArgs e)
{
if (kGrid.HitTest(e.X, e.Y).RowIndex < 0) return;
coordStatusLabel.Text = string.Format("X:{0} - Y:{1}", kGrid.HitTest(e.X, e.Y).RowIndex + 1,
kGrid.HitTest(e.X, e.Y).ColumnIndex + 1);
}
Peccato che il resto del tuo codice sia peggiore... esegue il metodo HitTest 3 volte invece di 1. :muro:
vero, lo esegue 3 volte.
preferisco se posso risparmiarmi 2 variabili int ,una HitTestInfo e uno StringBuilder. cmq il concetto era evitare di dichiarare variabili inutili, se proprio ti da fastidio eseguiro 3 volte uno hittest puoi tradurla così
private void kGrid_MouseMove(object sender, MouseEventArgs e)
{
var temp = kGrid.HitTest(e.X, e.Y);
if (temp.RowIndex < 0) return;
coordStatusLabel.Text = string.Format("X:{0} - Y:{1}", temp.RowIndex + 1,
temp.ColumnIndex + 1);
}
e hai comunque risparmiato 2 int inutili :
int nRow = 0;
int nCol = 0;
uno stringBuilder:
StringBuilder sb;
e hai usato l' hitTest una volta sola.
Contento? :p
lock cmpxchg8b %ebx
10-07-2010, 01:28
cmq il concetto era evitare di dichiarare variabili inutili, se proprio ti da fastidio eseguiro 3 volte uno hittest puoi tradurla così
http://i28.tinypic.com/15meiqc.gif
se mi dici cosa non ti è chiaro te lo posso spiegare
lock cmpxchg8b %ebx
10-07-2010, 13:17
se mi dici cosa non ti è chiaro te lo posso spiegare
Non mi è chiaro secondo quale criterio la variabile sarebbe inutile, visto che uno degli usi principali delle variabili è proprio quello di salvare un valore da usare più volte.
nRow, nCol e sb sono senza dubbio inutili (in questo caso). Ma hti proprio no.
Non mi è chiaro secondo quale criterio la variabile sarebbe inutile, visto che uno degli usi principali delle variabili è proprio quello di salvare un valore da usare più volte.
nRow, nCol e sb sono senza dubbio inutili (in questo caso). Ma hti proprio no.
Difatti hti è l'unica che ho riutilizzato anche io, anche se la mia si chiama temp.
Dipende poi dal metodo in gioco, spesso è più conveniente chiamare più volte um metodo anzichè dichiarare una variabile. Dipende.
Le altre inoltre sono assolutamente inutili, se uno non lo vede a colpo d'occhio vuol dire che non ha molta esperienza. Dichiarare variabili inutili è indice di scarsa programmazione, scarsa ottimizzazione del codice e scarsa leggibilità futura.
Secondo me bisogna trovare un giusto compromesso con la leggibilità. Togliendo tutte le variabili inutili si rischia di non far capire niente a chiunque altro legga il codice.
lock cmpxchg8b %ebx
10-07-2010, 16:44
Difatti hti è l'unica che ho riutilizzato anche io, anche se la mia si chiama temp.
Parlavo del tuo primo spezzone di codice.
Dipende poi dal metodo in gioco, spesso è più conveniente chiamare più volte um metodo anzichè dichiarare una variabile. Dipende.
Sicuramente non in questo caso. Fammi un esempio.
Dichiarare variabili inutili è indice di scarsa programmazione, scarsa ottimizzazione del codice e scarsa leggibilità futura.
Molto peggio chiamare un metodo come HitTest per ben 3 volte soltanto per avere 1 riga di codice in meno. MOLTO peggio.
Ripeto che dichiarare variabili inutili è indice di scarsa programmazione, scarsa ottimizzazione del codice e scarsa leggibilità futura.
Per quanto riguarda il mio codice ho tolto anche io le 3 chiamate al metodo. Ed ho comunque risparmiato la dichiarazione di 3 variabili inutili.
Inoltre ti posso assicurare che se tu avessi a che fare con liste di dati di una certa dimensione (parlo di liste Entity oltre le 100000 ad esempio) molto spesso, a discapito di un pò di tempo cpu perso, è molto meglio chiamare metodi tipo un orderby o un sort più volte pur di risparmiare l'orrore di copiare ogni volta un oggetto di quel tipo in un ulteriore variabile enorme.
Inoltre non dimentichiamoci che il metodo dal quale siamo partiri risponde alla chiamata di un evento di mouse move, questo vuol dire che viene chiamato una gran quantità di volte, e ogni volta si dovrebbe istanziare tutte quelle variabili inutili? per carità.
è vero che finiscono in garbage collection, ma è anche vero che la garbage del .net le pulisce ad ogni ciclo di garbage e non subito, quindi è un dispendio enorme di risorse per aggiornare una label. follia.
Non vedere che quelle 3 variabili in realtà ne generano a runtime quintali è un altro classico esempio di inesperienza.
Secondo me bisogna trovare un giusto compromesso con la leggibilità. Togliendo tutte le variabili inutili si rischia di non far capire niente a chiunque altro legga il codice.
Per questo è sempre buona norma commentare il codice, non c'è miglior modo per documentare quello che si scrive. Oltre ovviamente a cercare di rendere il codice leggibile, fidati che su progetti di una certa dimensione meno dichiarazioni si hanno e più si capisce. Altrimenti poi ti trovi ogni due secondi a cercare le variabili in giro per il sorgente. Cose del tipo "e questa variabile cos'è??? dove l'ha dichiarata??? aspetta che la cerco... a si eccola ok è un int, ma aspetta, sono sicuro che non la tocchi mai prima di arrivare dove stavo leggendo???? fammi scorrere bene il codice.... ok torno di là..... oh no e quest'altra???" ecc ecc ecc
Ripeto che dichiarare variabili inutili è indice di scarsa programmazione, scarsa ottimizzazione del codice e scarsa leggibilità futura.
Per quanto riguarda il mio codice ho tolto anche io le 3 chiamate al metodo. Ed ho comunque risparmiato la dichiarazione di 3 variabili inutili.
Inoltre ti posso assicurare che se tu avessi a che fare con liste di dati di una certa dimensione (parlo di liste Entity oltre le 100000 ad esempio) molto spesso, a discapito di un pò di tempo cpu perso, è molto meglio chiamare metodi tipo un orderby o un sort più volte pur di risparmiare l'orrore di copiare ogni volta un oggetto di quel tipo in un ulteriore variabile enorme.
Inoltre non dimentichiamoci che il metodo dal quale siamo partiri risponde alla chiamata di un evento di mouse move, questo vuol dire che viene chiamato una gran quantità di volte, e ogni volta si dovrebbe istanziare tutte quelle variabili inutili? per carità.
è vero che finiscono in garbage collection, ma è anche vero che la garbage del .net le pulisce ad ogni ciclo di garbage e non subito, quindi è un dispendio enorme di risorse per aggiornare una label. follia.
Non vedere che quelle 3 variabili in realtà ne generano a runtime quintali è un altro classico esempio di inesperienza.
Scusa riguardando l'originale ho visto che i due int sono dichiarati fuori dal metodo. magnifico..... questa sì che è rpogrammazione.... a quando le variabili static e i global per aggiornare una label??? eheheheheheh
lock cmpxchg8b %ebx
10-07-2010, 17:42
Per quanto riguarda il mio codice ho tolto anche io le 3 chiamate al metodo.
Si, dopo che te l'ho fatto notare io.
Inoltre ti posso assicurare che se tu avessi a che fare con liste di dati di una certa dimensione (parlo di liste Entity oltre le 100000 ad esempio) molto spesso, a discapito di un pò di tempo cpu perso, è molto meglio chiamare metodi tipo un orderby o un sort più volte pur di risparmiare l'orrore di copiare ogni volta un oggetto di quel tipo in un ulteriore variabile enorme.
Non so perché tu stia spostando la discussione sulle liste ed i metodi di IEnumerable (o meglio, lo so, ma preferisco evitare), ma vorrei ricordarti che stavamo parlando di HitTest.
Inoltre non dimentichiamoci che il metodo dal quale siamo partiri risponde alla chiamata di un evento di mouse move, questo vuol dire che viene chiamato una gran quantità di volte, e ogni volta si dovrebbe istanziare tutte quelle variabili inutili? per carità.
è vero che finiscono in garbage collection, ma è anche vero che la garbage del .net le pulisce ad ogni ciclo di garbage e non subito, quindi è un dispendio enorme di risorse per aggiornare una label. follia.
Non vedere che quelle 3 variabili in realtà ne generano a runtime quintali è un altro classico esempio di inesperienza.
Hai qualche serio problema di comprensione?
nRow, nCol e sb sono senza dubbio inutili
vabbhe dai chiudiamo la questione mi pare tu la voglia spostare in polemica e non mi interessa.
Cmq il mio era solo un esempio che mi avevi chiesto.
Ad ogni modo hai ragione su tutto basta che non ti scaldi per niente.
amici come prima
ciao
RaouL_BennetH
12-07-2010, 14:01
Scusa riguardando l'originale ho visto che i due int sono dichiarati fuori dal metodo. magnifico..... questa sì che è rpogrammazione.... a quando le variabili static e i global per aggiornare una label??? eheheheheheh
Ciao :)
Innanzitutto, grazie anche a te per il contributo, per aver condiviso parte della tua esperienza e per l'aver dedicato parte del tuo tempo nel suggerirmi una buona soluzione al problema.
Gli inesperti (in questo caso io) chiedono aiuto/consiglio proprio ai più esperti. L'uso di un forum tecnico non credo che servirebbe a molto se fossimo già tutti la in cima e se nessuno avesse bisogno di aiuto.
Ci sono molti esperti qui che, fortunatamente per me (e per tutti quelli inesperti come me), hanno contribuito e contribuiscono con la loro conoscenza, la loro esperienza e non ultima la loro pazienza, a condividere il loro sapere senza guardarci dall'alto in basso.ò
Aggiungo, e chiudo, che dalla parte del "basso" ci si passa tutti, ma non tutti hanno la capacità di ricordarselo :)
RaouL.
Ciao :)
Innanzitutto, grazie anche a te per il contributo, per aver condiviso parte della tua esperienza e per l'aver dedicato parte del tuo tempo nel suggerirmi una buona soluzione al problema.
Gli inesperti (in questo caso io) chiedono aiuto/consiglio proprio ai più esperti. L'uso di un forum tecnico non credo che servirebbe a molto se fossimo già tutti la in cima e se nessuno avesse bisogno di aiuto.
Ci sono molti esperti qui che, fortunatamente per me (e per tutti quelli inesperti come me), hanno contribuito e contribuiscono con la loro conoscenza, la loro esperienza e non ultima la loro pazienza, a condividere il loro sapere senza guardarci dall'alto in basso.ò
Aggiungo, e chiudo, che dalla parte del "basso" ci si passa tutti, ma non tutti hanno la capacità di ricordarselo :)
RaouL.
Ma certo, ci mancherebbe. Abbiamo tutti da imparare, io per primo. Quando posso cerco di dare una mano a te che magari non sai una cosa, domani tu darai una mano a me che non ne so un altra. Questo mi sembra il modo giusto di sfruttare un forum.
Per quanto riguarda l'inciso che hai quotato non voleva assolutamente apparire un insegnamento (dio mi salvi da chi ha la pretesa di insegnare) voleva essere uno spunto ironico su cui riflettere dell'opportunità di utilizzare variabili "globali" quando magari non servono.
Detto questo, ripeto, ho anche io ancora da imparare molto nonostante tutti gli anni di programmazione che ho alle spalle, nonostante le certificazioni che ho conseguito e nonostante tutti i corsi e libri che ho letto quindi figurati se ho intenzione di venire quì a insegnare.
Ripeto che dichiarare variabili inutili è indice di scarsa programmazione, scarsa ottimizzazione del codice e scarsa leggibilità futura.
Dissento.
Variabili di questo tipo , ovvero gli shortcut di valori gia' esistenti, sono inseiriti spesso proprio per la loro leggibilita'.
L'ottimizzazione non viene inficiata, dato che se una di quelle variabili viene usata anche solo 2 volte, allora e' meglio l'esistenza dello shortcut stesso piuttosto che la sua assenza.
Quando invece dovesse venire usata 1 volta sola, come in questo caso, il compilatore la bypassa direttamente e non viene effettivamente allocata alcuna variabile a runtime.
Quindi tutto tranne che scarsa programmazione.
è vero che finiscono in garbage collection, ma è anche vero che la garbage del .net le pulisce ad ogni ciclo di garbage e non subito, quindi è un dispendio enorme di risorse per aggiornare una label. follia.
Non vedere che quelle 3 variabili in realtà ne generano a runtime quintali è un altro classico esempio di inesperienza.
Dissento anche qui.
Le variabili locali del tipo qui trattato, ovvero gli shortcut, risiedono nello stack, e non nell'heap.
E per questo non partecipano al garbage collector, e il loro eventuale spazio usato viene rilasciato immediatamente durante il codice di ritorno del metodo.
parlavo dei 2 int e dello stringbuilder. Francamente non credo che risiedano nello stack, Anzi sono abbastanza certo che finiscano nell'heap.
Forse l'unica che rimane in stack sarebbe proprio la famosa hti, se fosse vero quello che dici allora chiamare 3 volte il metodo hittest oppure dichiarare una variabile che il compilatore userebbe solo come shortcut non farebbe alcuna differenza, francamente anche su questo sono molto dubbioso.
Ad ogni modo prendo per buone le tue affermazioni perchè purtroppo non ho tempo adesso di approfondire.
Magari se avrò tempo darò una controllata.
Anzi. lo stringBuilder finisce senza dubbio nell'heap. è un oggetto complesso non un valuetype e per sua natura non può risiedere nello stack. per quando riguarda i due int se fossero stati definiti all'interno del metodo probabilmente sarebbero rimasti e morti con lo stack ma sono stati dichiarati fuori e valorizzati nel metodo, quindi anch'essi necessitano di fare riferimento all'heap.
l'hitTestInfo anch'esso finisce dritto nell'heap non essendo neanche lui un value type. Sostanzialmente sono finite tutte nell'heap e partecipano alla grande alla garbage collection.
parlavo dei 2 int e dello stringbuilder. Francamente non credo che risiedano nello stack, Anzi sono abbastanza certo che finiscano nell'heap.
Quei 2 int finirebbero nello stack. Sicuro.
Basta dichiararli dentro e non fuori.
Forse l'unica che rimane in stack sarebbe proprio la famosa hti, se fosse vero quello che dici allora chiamare 3 volte il metodo hittest oppure dichiarare una variabile che il compilatore userebbe solo come shortcut non farebbe alcuna differenza, francamente anche su questo sono molto dubbioso.
Assolutamente no. Ho detto l'opposto.
Quando un metodo dovesse venire usato 2 o piu' volte, allora conviene prenderne riferimento come shortcut, come nel caso della famosa hti.
Quindi, come gìà ho scritto, finisco tutte nell'heap così come era il codice....
a questo punto non capisco cosa c'entra il tuo discorso......
hti non è uno shortcut, è un oggetto e come tale non può stare nello stack.
Quindi, come gìà ho scritto, finisco tutte nell'heap così come era il codice....
a questo punto non capisco cosa c'entra il tuo discorso......
Allora, lo Stringbuilder l'abbiamo gia' ucciso al quarto post.
E sicuramente sarebbe stato nell'Heap, ma non perche' "E' un oggetto complesso", ma perche' finisce nell'Heap tutto e solo cio' che e' allocato mediante new.
Le 3 chiamate a kGrid.HitTest(e.X, e.Y) e' bene evitarle.
Bene farne una sola e tenerne il risultato in una variabile che risiedera' appunto nello stack.
Viceversa "sprecare" due interi per le coordinate, che risiederanno nello stack, e' fattibile e non peggiora le performance ne la leggibilita (anzi, la maggior parte delle volte la migliora).
hti non è uno shortcut, è un oggetto e come tale non può stare nello stack.
tutto in C# e' un oggetto e deriva da object. Questa frase non ha alcun senso.
io continuo a parlare del codice originale e non di quello dopo n post.
cmq ti sbagli fortemente in .net i type si dividono in due gruppi;
i value types:
bool
byte
char
decimal
double
enum
float
int
long
sbyte
short
struct
uint
ulong
ushort
e i referce type
class
interface
delegate
object
string
i reference type risiedono sempre e solo nella heap, i value type invece possono stare anche solo nello stack e dipende dal loro utilizzo.
Stai facendo confusione con la system.Object che in questo caso non c'entra nulla. Per oggetto complesso si intende reference type, quindi classi, object, ecc ecc non quello che deriva dalla object. Tutto è riconducibile a object ma i value types derivano da System.ValueType. Per "castarli object" è necessaria una operazione di boxing e "guarda caso" appena lo fai il valuetype viene sparato immediatamente nella heap.
Inoltre non finisce nell'heap tutto ciò che è allocato mediante new, assolutamente no, finiscono nell'heap tutti i reference type obbligatoriamente. Non far confusione sul fatto che in genere i reference type sono proprio quelli che inizializzi con un new, non è proprio quello il punto. Mentre i value type tipende da dove sono definiti o se subiscono operazioni di boxing unboxing.....
Per finire continuo a dire che io parlavo del codice che ha aperto il 3d e lì di variabili che rimangono nello stack non ne vede neanche una, quindi il tuo primo intervento dove sostenevi che neanche una di quelle variabili sarebbe stata nell'heap era completamente errato, detto questo possono sbagliare tutti, io sono andato a rivedere prima di risponderti, di primo impatto ti ho dato ragione perchè non ero fresco sull'argomento. Però una volta che si certifica come stanno le cose è bene spiegarle anche per chi ci legge.
[QUOTE=gugoXX;32589934]ma perche' finisce nell'Heap tutto e solo cio' che e' allocato mediante new.[QUOTE]
Mi sono accorto adesso di un secondo errore, non solo non è vero che finisce nell'hep tutto ciò che si inizializza mediante new (non ci finisce per questo motivo ma per la spiegazione che ti ho dato prima).
Ma non è vero neanche che ci finisce solo quello che è inizializzato mediante new.
Ad esempio:
int a = 5; //a meno di particolari utilizzi questa finisce in stack perchè è un valueType
var b = (object)a; //questa finisce in heap immediatamente(senza alcun new)
Non solo.
Se io dichiaro un valueType ma lo dichiaro dentro un refereceType finisce nell'heap di nuovo, senza nessun new ovviamente....
public class miaClasse
{
public int a = 5; //questo finisce dritto nell'heap
}
invece se io sono in un metodo
public int somma()
{
int a = 5; //rimane nello stack
int b = 6; //rimane nello stack
return a+b;
}
Spero di aver chiarito un pò come funziona, se volete approfondisco, mi pare che ci sia un pò di confusione.
io continuo a parlare del codice originale e non di quello dopo n post.
cmq ti sbagli fortemente in .net i type si dividono in due gruppi;
i value types:
bool
byte
char
decimal
double
enum
float
int
long
sbyte
short
struct
uint
ulong
ushort
e i referce type
class
interface
delegate
object
string
Guarda che mi e' chiarissimo, come anche a tanti altri che leggono qui.
Il problema e' che tu hai scritto solo
oggetto
E ancora, di nuovo, tutto in C# e' un oggetto.
oggetto = object = System.Object
Alcuni sono reference type, altri sono value type.
Ma sono tutti oggetti, e quando si sta proprio parlando delle loro differenze, scrivere solo "oggetto" non e' sufficiente.
Non ci credi?
Pova un po'
int t = 15;
if (t is object )
Console.WriteLine("E' un oggetto");
var b = (object)a; //questa finisce in heap immediatamente(senza alcun new)
Se sai cos'e' il boxing, allora saprai anche che qui c'e' un "new" implicito.
Forse ti conviene ripassare la parte sull'allocazione, perche' mi sembra che tu abbia un po' di confusione.
Qualche post fa parlavi addirittura di garbage collection e 2 interi, e ti preoccupavi della loro crezione e distruzione.
eheheheh, guarda che non ho detto io cose tipo che tutte quelle variabili risiedevano nello stack quando invece neanche una ci andava
oppure che finisce nell'heap tutto e solo ciò che si inizializza tramite new quando proprio non c'entra nulla
mi preoccupavo proprio perchè i due interi sono stati dichiarati all'interno della form, che un referenceType e di conseguenza finiscono dritti nell'heap e partecipano alla garbage. NOn c'è niente di strano
Inoltre non ho mai detto che non tutto in net è un oggetto, lo so bene, ma ci sono delle differenze che non coglievi e te le stavo spiegando.
oh finalmente ho trovato la paginetta microsoft che spiega esattamente tutto quello che ho detto. ti spiega perchè il new non c'entra una mazza, ti spiega il perchè della divisione tra value type e tra reference type, ti spiega che sono i reference type che risiedono nell'heap.... e non perchè si inizializzano con un new..... e che i valueType finiscono anch'essi nell'heap in determinati casi e quindi partecipano alla garbage....
ooooooooooooooohhhhh, almeno se non credi a me a msdn crederai...
I tipi di dati sono distinti in tipi di valore e tipi di riferimento. I tipi di valore sono allocati sullo stack oppure inline in una struttura. I tipi di riferimento sono allocati sull'heap. Sia i tipi di valore che i tipi di riferimento sono derivati dalla classe base finale Object. Qualora fosse necessario che un tipo di valore presenti un comportamento simile a un oggetto, per fare in modo che il tipo di valore assuma la funzione di oggetto di riferimento viene allocato un wrapper all'heap, nel quale viene copiato il valore del tipo di valore. Il wrapper viene contrassegnato in modo che il tipo di valore in esso contenuto sia riconosciuto dal sistema. Questo processo è definito boxing, mentre il processo inverso è detto unboxing. Tramite questi due processi è possibile gestire qualsiasi tipo come oggetto.
http://msdn.microsoft.com/it-it/library/system.valuetype(VS.80).aspx
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.