Newsgroup: it.comp.programmare.win32
Titolo: WM_COPYDATA and SendMessage

Salve a tutti.
Ho un piccolo problema che spero potrete aiutarmi a risolvere... Allora, ho
un'applicazione scritta in C (un plug-in) che utilizza il messaggio
WM_COPYDATA per comunicare con un'applicazione VisualBasic. Il problema è
che il plug-in rimane bloccato sulla SendMessage finché l'applicazione VB
non ha finito di processare il messaggio: esattamente che messaggio dovrebbe
mandare l'applicazione VB al plug-in per indicare che il messaggio è stato
ricevuto e che la SendMessage può ritornare?
Grazie!
Fra.

:

Se la chiamata a SendMessage non avviane dallo stesso thread che riceve il 
messaggio (usare WM_COPYDATA in questo contesto sarebbe oltretutto 
inutile), puoi provare a richiamare ReplyMessage dopo che il programma 
ricevente ha fatto una copia dei dati da utilizzare, ma prima di passare 
all'elaborazione degli stessi (la copia potrebbe essere inutile, ma ti 
consiglio di provare e di lasciarla se questo non rallenta 
significativamente l'esecuzione).
L'unica incognita è come possa comportarsi VB in questa situazione 
"anomala".
-- 
Valter Minute
min...@inwind.it
 (the reply address of this message is invalid)

 inutile), puoi provare a richiamare ReplyMessage dopo che il programma
Si, la SendMessage avviene tra thread diversi. Purtroppo ReplyMessage non va
bene perchè "by design" non restituisce il controllo alla funzione bloccata
sulla SendMessage, che è proprio quello che io voglio fare. Qualcuno sa se
esiste un messaggio che mandato alla finestra "bloccata" comunichi
l'avvenuta ricezione del messaggio e sblocchi la funzione che ha chiamato la
SendMessage?
Fra.

Come non detto, funziona la ReplyMessage! Grazie mille, mai fidarsi
ciecamente dell'MSDN....
Fra.


Sì, effettivamente la spiegazione iniziale è decisamente fuorviante...
comunque nei remarks recita:
By calling this function, the window procedure that receives the message 
allows the thread that called SendMessage to continue to run as though the 
thread receiving the message had returned control. The thread that calls 
the ReplyMessage function also continues to run. 
Probabilmente il primo paragrafo và letto come:
La funzione ReplyMessage viene utilizzata per ritornare un valore in 
risposta a un messaggio inviato tramite SendMessage senza ritornare dalla 
wndproc.
Il mio inglese è pessimo, ma se in due abbiamo capito la stessa cosa 
(sbagliata), credo che la frase si potesse scrivere comunque in modo meno 
ambiguo :)


Si in effetti leggere in Inglese non aiuta la comprensione dei punti sottili
:-). Ora però ho un altro problema un po' complicato...
Allora, durante l'esecuzione del mio programma eseguo un ciclo di questo
genere:
if (!IsWindow(dialogHWND))
{
    dialogHWND=CreateDialog(gHINSTANCE, MAKEINTRESOURCE(IDD_DIALOG1), gHWND,
(DLGPROC) DialogProc);
    ShowWindow(dialogHWND, SW_SHOW);
}
while (GetMessage(&message, NULL, 0, 0))
{
    if (!IsWindow(dialogHWND) || (!IsDialogMessage(dialogHWND, &message))
    {
        TranslateMessage(&message);
        DispatchMessage(&message);
    }
}
La parte importante è la IsDialogMessage( ), che una volta chiamata gestisce
automaticamente i messaggi relativi alla pressione del tasto TAB o alle
combobox, ecc. Tutto bene, ma all'interno della DialogProc ho bisogno di
creare altre finestre (altre chiamate a CreateDialog) ma non posso inserire
altri cicli "while(GetMessage(...)>0)" perché rimarrebbero "attivi" fino ad
una chiamata a PostQuitMessage( ) e quindi perdo gli effetti "benefici"
della IsDialogMessage( )... Come posso risolvere questo problema?
Grazie ancora,
Fra.




Se tutte le dialog modeless che hai usato sono dialog "standard" (o 
comunque appartengono a una stessa classe), potresti utilizzare il nome 
della classe stessa o (più rapido) l'indirizzo della WndProc (se non fai 
subclassing delle dialog, ovviamente) per decidere se richiamare o meno 
IsDialogMessage.
Potresti anche usare criteri più "empirici" (ex: lo stile della finestra o 
il fatto che abbia un determinato owner, appartenga a un determinato 
thread...) validi solo dentro la tua applicazione (e sicuramente più veloci 
di un confronto tra i nomi di classe).
In alternativa, potresti tenere una lista delle finestre attive e 
richiamare IsDialogMessage solo se la finestra cui è associato il messaggio 
è compresa nella lista (in questo modo potresti gestire un numero 
illimitato di dialog). Ovviamente la lista delle finestre dovrà essere 
accessibile a tutte le finestre che hanno la necessità di tradurre i 
messaggi dialog.
Se le finestre non-dialog non hanno nessun bisogno di navigazione da 
tastiera, puoi anche richiamare IsDialogMessage su tutte le finestre...
P.S. in questo ng c'è parecchia altra gente che è in grado di fornirti 
spiegazioni migliori delle mie quindi, quando cambi "topic", ti consiglio 
di iniziare un nuovo thread e non accodarlo a quello precedente.
