Newsgroup: it.comp.lang.visual-basic
Titolo: Subclassing e WindowsProcedure

Sto facendo qualche esperimento con il subclassing, tanto per vedere 
come funziona...ma una cosa non mi e' chiara: se effettuo il subclassing 
di un controllo (commandbutton, optionbutton, checkbox, ecc.), 
sostituendo alla sua WindowProcedure una scritta da me, devo comunque 
ricordarmi l'indirizzo della WindowProcedure originale (ottenuto con 
l'istruzione GetWindowLong(Oggetto.hWnd, GWL_WNDPROC)) per OGNI 
controllo che 'subclasso' (termine fetidissimo, ma rende l'idea 8-)), e 
rimettere le cose a posto quando scarico la form, o all'Unload di detta 
form le cose vengono resettate in automatico (una specie di 'Garbage 
Collection' delle WindowProcedure)?
Ho evidenziato 'OGNI' perche' dalle prime prove sembra che l'indirizzo 
ritornato dalla GetWindowLong sia sempre lo stesso, indipendentemente 
dal controllo che subclasso (ci risiamo...) ...e' un caso, o e' cosi' 
effettivamente?
Grazie per le informazioni
-- 
Bye by SixaM 8-]
-----------------------------
Sito comune: 
www.it-lang-vb.net


è vero anche se la cosa mi risulta abbastanza strana; se fai qualche
controllo in più ti accorgi che anche la window procedure di classe
(GetClassLong/GCL_WNDPROC) è la stessa per i vari controlli (o almeno per i
controlli "standard" di VB);
dopo una rapida analisi con lo spy++, l'unica ipotesi che posso fare è che
la window procedure interna di vb riesca a distinguere il tipo di finestra
da gestire in base agli extra bytes della classe (da prove fatte ho visto
che una form ne ha solo 2, una textbox 8 e un command button 6);
il significato di tali bytes è strettamente dipendete dall'applicazione che
registra le classi di finestra e che implementa la window procedure
opportuna (traduzione: dio solo e pochi altri sanno cosa cosa vuol dire
quello che c'è scritto ;)))
magari se c'è qualcuno che ha maggiori informazioni a riguardo potrebbe fare
cosa gradita a molti se si facesse avanti ;))
per il resto, secondo il mio parere, faresti bene a non basare la logica di
subclassing sul fatto che la window procedure sia la stessa; l'overhead di
un simile approccio è infatti trascurabile (a meno che tu non debba
subclassare qualche centinaio di controlli di una stessa form... in tal caso
auguri) e inoltre ti cauteli contro eventuali (anche se improbabili) cambi
di filosofia di microsoft magari un una prossima SP6;
ciao

 form ne ha solo 2, una textbox 8 e un command button 6);
La window procedure riceve  l'handle della window, quindi è in grado
di sapere tutto quello che serve slla finestra.
Ciao.
--
BSD is for UNIX-lovers -- linux is for Windows-haters.

 di sapere tutto quello che serve slla finestra.
ovvio, ma trovo l'organizzazione lowlevel del codice piuttosto bizzarra, in
altre parole, la windowproc di vb dovrebbe fare qlc cosa del tipo:
...
WNDPROC realWindowProc;
realWindowProc = (WNDPROC) GetWindowLong(hWnd, GWL_USERDATA);
return realWindowProc(hWnd, Msg, wParam, lParam);
...
dal momento che la gestione dei messaggi per ogni singolo controllo (o per
la form stessa) non è ovviamente la stessa (tranne forse per alcuni
messaggi);
ma, ripensandoci, forse il tutto deriva da una gestione "a tabelle"
dell'intero meccanismo RAD-based di vb; in altre parole probabilmente il
valore di ritorno di GetWindowLong rappresenta l'indice di una qlc tabella
per mezzo della quale viene generalizzata la gestione degli eventi di vb e
la gestione lowlevel dei vari messaggi; qualcosa del tipo:
...
LONG vbControlId = GetWindowLong(hWnd, GWL_USERDATA);
ManageVbEvent(vbControlId, Msg, wParam, lParam);
...
dove presumibilmente all'interno di ManageVbEvent viene
1) gestita la pre-eleborazione del messaggio a basso livello
2) eventualmente viene generato il RaiseEvent
3) gestita la post-elaborazione del messaggio a basso livello
ovviamente, tramite vbControlId viene fatto un lookup all'interno di una
tabella che ha n-entrate per tuttli gli n-componenti presenti nella form
(compresa la form stessa)
ma tutta questa è solo fanta-informatica ;)) (mi sono lasciato un po
andare...)
magari però, se ci fosse qlc sviluppatore del core di vb in ascolto, mi
piacerebbe fare due chiacchiere ;))
ciao

 (tranne forse per alcuni messaggi);
Sinceramente non ho idea di come le cose stiano veramente, ma
potrebbe benissimo esserci una sola window procedure.
