Newsgroup: it.comp.programmare.win32
Titolo: Thread di interfaccia utente (HELP)

Qualcuno ha per caso utilizzato (in qualche programma) thread di interfaccia
utente?
Io l'ho fatto e fino a che compilo l'eseguibile nella versione di debug tutto
funziona a meraviglia!
Se invece compilo in versione release il programma va in errore.
Il Problema nasce dopo avere risposto ad un evento (utente) inviato al thread
attraverso PostThreadMessage(...).
Scendendo ancora più in dettaglio ho visto che il problema non stà nella
routine di elaborazione del messaggio bensì nel codice di rientro della
funzione (MFC) DispatchThreadMessageEx(...), in pratica al momento del ritorno
lo Stack Pointer non punta alla locazione che contiene l'indirizzo di ritorno e
quindi il programma esegue un salto non valido!!!!!!!!!!!
C'è per caso qualcuno che mi può dare una dritta?!?!?!
massi  
-- 
Posted from 
ppp-105-103.25-151.libero.it
 [151.25.103.105] 
via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 C'è per caso qualcuno che mi può dare una dritta?!?!?!
Controlla che i parametri (tipo e numero) delle funzioni collegate ai 
messaggi siano corretti. Controlla su MSDN.
La versione debug mette a posto automaticamente lo stack, quella release, 
invece, scoppia.
-- 
Luc.


Mette a posto automaticamente e' na parola grossa... Non muore, ma ti da' un
warning per ESP non valido, altrimentiche debug e'? :)
Ciaotutti,
*

 Se invece compilo in versione release il programma va in errore.
Prova ad eliminare le ottimizzazioni (di velocità o  di dimensione del
codice) dalla versione release.
Tali ottimizzazioni spesso danno per scontati alcuni passaggi che non lo
sono, ad esempio può capitare che un puntatore perda il suo valore nel
passaggio da una routine all'altra.
Nello specifico non ho mai utilizzato thread d'iterfaccia utente ma il
problema potrebbe essere della natura che ti ho proposto.
Se non vuoi rinunciare alle ottimizzazioni utilizza la direttiva #pragma
optimize( "[optimization-list]", {on | off} ).
Ti consentirà di decidere funzione per funzione il metodo migliore per
ottimizzare il codice.
Vedi su MSDN per maggiori dettagli!
Spero ti sia di aiuto.
Ciao

 Luc.
....il Problema stava proprio quì!!!!
Richiamavo PostThreadMessage passando due valori WPARAM e LPARAM nulli (in
effetti non mi servivano...)
Quindi la routine di elaborazione del messaggio non aveva parametri.
Dopo avere adeguato la routine di elaborazione tutto funziona anche in versione
release!!!!
Grazie per l'aiuto!!
Massi
-- 
Posted from 
ppp-253-23.25-151.libero.it
 [151.25.23.253] 


 ....il Problema stava proprio quì!!!!
Non ne dubitavo, credimi. Ho avuto lo stesso problema io.
-- 
Luc.

 passaggio da una routine all'altra.
Questa mi sembra un'accusa molto grave, dato che in sostanza equivale a dire
che l'ottimizzatore di un compilatore non funziona. Potresti spiegarti
meglio?
--
Bye! Lorenzo Lutti

 Bye! Lorenzo Lutti
Sorry per il ritardo...problemi di connessione ADSL
Bhe... a me è successo che una mia applicazione funzionasse in debug e non
in release... (almeno due esempi distinti in procedura e tipologia di
codice).
Ho cercato spiegazioni nel codice procedendo con un debug
"maccheronico"(leggi msgbox piazzate qua e là per individuare l'errore),
trovato il pezzo di codice incriminato e verificatane la correttezza ho
pensato al BUG microsoft (se escludi l'irrazionale quel che rimane pur se
improbabile deve essere la realtà) ho cercato su MSDN ed ho trovato questo:
<<Optimizing compilers can sometimes change your code to something you
wouldn't expect. If you find that the application works when you build for
release without optimizations, but not when you build for release with
optimizations, this might be the case.
If you suspect that a particular portion of your code is not being optimized
correctly and is causing problems in the compilation or running of your
program, you can bracket the offending code with
#pragma optimize("", off)
and
#pragma optimize("", on)
Developers have also been able to trace the bad code being generated when
are on by looking at the actual assembly code generated for a function.>>
Quindi nessuna accusa, semplice constatazione! Comunque per quel che
riguarda il passaggio da debug a release può essere utile anche: "Common
Problems Switching from Debug to Release Build" sempre su MSDN.
P.S. Per quel che riguarda l'esempio, a me è successo, non so se questo sia
dipeso da un errore mio o dal processo di ottimizzazione ma cmq cambiando i
parametri dell'ottimizzazione il problema nn si è più presentato.
Saluti