Newsgroup: it.comp.programmare.win32
Titolo: Window procedure

Sicuramente è una domanda banale ma la faccio lo stesso perchè sto avendo
problemi. Le Window Procedure, e quindi tutte le variabili in esse
contenute, vengono condivise tra le varie finestre di una stessa classe? In
teoria no, ma mi sta accadendo che varie finestre di una stessa classe (da
me creata) risentano ognuna delle modifiche apportate dalle altre alle
variabili della window procedure (naturalmente le variabili statiche). Voi
che ne pensate?
Ciao, Giuseppe
---------------------------------------------------------------------------
_Guybrush su IRCNet canale #programmazione
ICQ: 42227764
---------------------------------------------------------------------------

 che ne pensate?
in generale, l'utilizzo di variabili statiche va bene per finestre singole
(come ad esempio la finestra principale dell'applicativo); negli altri casi
bisogna utilizzare un metodo come quello descritto in precedenza.
Stefano.

 che ne pensate?
Se sei entro lo stesso processo, il comportamento che osservi e` esattamente
quello previsto.
Se, come sembra, vuoi associare dati a specifiche istanze di finestre, usa
il parametro cbWndExtra della struttura WNDCLASSEX che passi all'API
RegisterClassEx, e GetWindowLong/SetWindowLong per accedere a quei
dati; ovvero, SetProp e GetProp, per associare i dati come "proprieta`"
esterne alla window stessa (prestazioni meno spinte, ma metodo "non
invasivo", e come tale applicabile senza bisogno di intervenire sulla window
class, il che puo` evitare necessita' di subclassing/superclassing &c, e
inoltre piu` flessibile).
Alex




bisogna utilizzare un metodo come quello descritto in precedenza.
Non ho ripostato la tua risposta quotata perchč, oltre ad esserti molto
grato per tutte le info che mi hai dato, concordo con tutto quello che hai
detto.
Tantissime grazie ancora


inoltre piu` flessibile).
Per quello che devo fare io preferisco GetWindowLong/SetWindowLong (ho pochi
dati da trattare).
Grazie per le info e per l'interessamento.


[Mega -SNIP]
Sinceramente preferisco il codice C per il Win, mi ci trovo molto piů a mio
agio :-)



I cast C style in C++ non sono molto sicuri, quelli new-style del C++
soffrono di minori problemi e la loro sintassi permette di individuarli
facilmente.
Paolo
-----------------------------------------------------------------
  Paolo Marotta
  Computer Science, University of Pisa
  home:   
http://www.cli.di.unipi.it/~marotta
-----------------------------------------------------------------

 wrote in message
37f8f1b7...@proxy.cli.di.unipi.it...


 Sinceramente preferisco il codice C per il Win, mi ci trovo molto più a


grandi/giganti.
Sono d'accordo con te, ma per ora non voglio complicarmi la vita.
Ciao, Giuseppe
---------------------------------------------------------------------------


winproc processa molti messaggi.
Io non lo farei: il numero di messaggi postati ad una WindowProc è
innumerevole rispetto a quelli che vengono processati. Faresti calare di
molto le performances (già di per se basse sotto Windows).


Ciao, Giuseppe
Saluti,
    Mardy

del dato di GetWindowLong)
I messaggi che possono essere inviati ad una Window Proc sono circa 850. Non
credo che normalmente ne vengano processati più di 20......


Ciao, Giuseppe
Saluti,
    Mardy

Mardy secondo me ciò che dici è un insulto all'ottimizzazione , che tra le
prime sue leggi dice di evitare la ripetizione di codice inutile all'interno
dei loop (e nel caso della WP a maggior ragione) , oltretutto per una cosa
che ti serve si e no un quinto delle volte volendoti bene. Poi l'esempio che
fai è allucinante "non noto alcun rallentamento nella velocità del
cursore.." prova ad esaminare il tempo medio che impiega la sola Window
Procedure con un buon Profiler con e senza il tuo codice ridondate... vedrai
quanto rallenta ! Tu dirai sono ms , ma se poi ti capita lo stesso errore in
casi differenti ?
Se poi ti preoccupa l'occupazione di memoria basta utilizzare coerentemente
l'istruzione switch della processmessage..per esempio così..
switch(message)
    {
    qui metti tanti case quanti sono i messaggi che intercetti..
    poi ci metti la tua chiamata..( ed eventualmente tutto il codice
ridondante nelle elaborazioni dei messaggi)
    poi fai un altra istruzione switch(message) per il processamento dei
messaggi..
    Lo "spreco" di memoria (se c'è bisogna vedere quanto codice ridondante
hai) è minimo e i vantaggi dell'ottimizzazione
    vengono assicurati.(nessun codice eseguito inutilmente)
    }
--
Ciao , Ricardo Antonio Piana
ricard...@tiscalinet.it
http://web.tiscalinet.it/ricardopiana
***

Ciao , Ricardo Antonio Piana
Saluti,
    Mardy

bytes sono praticamente insignificanti. :-(
Come ha detto Riccardo Antonio Piana il tuo discorso è un attentato alle
prestazioni, infatti concordo in tutto e per tutto con quello che trovi
scritto nel suo messaggio.


momento di ottimizzare probabilmente faro' come dite tu e Giuseppe.
Il problema e che se la tua app è molto complessa risulta un pò difficile
ottimizzare efficientemente a programma terminato.


 ottimizzare efficientemente a programma terminato.
ed aggiungo io , così lo scrivi due volte... (ma quanto tempo che avete
ragazzi , nessuno che vi dice che il programma deve essere pronto per ieri ,
nessuna fretta , l'ideale per dar sfogo alla creatività...)
Ciao , Ricardo Antonio Piana
(Rico per gli amici)
ricard...@tiscalinet.it
http://web.tiscalinet.it/ricardopiana
***

Ciao, Giuseppe
Saluti,
    Mardy

Ciao , Ricardo Antonio Piana
Saluti,
    Mardy

quelli del processore, dell'ordine delle decine di nanosecondi.
In generale adottato l'algoritmo di complessita` ottima, ulteriori
ottimizzazioni vengono fatte sulla base del problema.
Oggi quello che conta e` la velocita` e solo secondariamente la
memoria (che costa molto meno di un processore).
Oltretutto un risparmio di pochi byte non si traduce necessariamente
in guadagno dato che la memoria e` solitamente allocata a
pagine...


Di' un po', ma ti diverti proprio tanto a rigirare il coltello nella piaga?
;-)
Si, è un mio hobby :-)


    Mardy

Paolo
Saluti,
    Mardy

Ciao, Giuseppe
Saluti,
    Mardy

saranno tra i 16 ed i 20, in ogni caso ben lontani da 1 millisecondo.
cioe` tra 4000 e 5000 nsec a 400Mhz significa che il ciclo di clock e`
di 2.5 nsec (se non sbaglio) e quindi perdi ben 1600-2000 cicli
in cui potresti eseguire non so quante decine (centinaia)
di istruzioni.
Sempre una eternita` e`, e comunque una porzione considerevole
del quanto di tempo che la tua applicazione riceve!


avevo pensato. :-(
Quando l'applicazione si ferma ad aspettare l'input dell'utente non
occupa inutilmente il processore (attesa attiva), ma lo rilascia in
favore di un'altra applicazione (attesa passiva) per essere risvegliata
quando arriva l'input dell'utente. In tal modo il sistema risulta
ottimizzato nel complesso.


il danno e' evidente. Va be', rimediero', rimediero'... :-)
Mi fa piacere che ti sia convinto :-)


Ciao, Giuseppe
Saluti,
    Mardy