View Full Version : [c++] catturare eventi propri...
Sono a conoscenza delle routine degli eventi.
Un esempio:
LRESULT CALLBACK MsgProc( HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam, bool* pbNoFurtherProcessing, void* pUserContext )
{
...
return 0;
}
ancora:
void CALLBACK OnGUIEvent( UINT nEvent, int nControlID, CDXUTControl* pControl, void* pUserContext )
{
switch( nControlID )
{
case IDC_ADDACTORS:
{
...
break;
}
case IDC_REMOVEACTORS:
{
...
break;
}
case IDC_CHANGEGRAVITY:
{
... }
}
}
ancora:
LRESULT CALLBACK DXUTStaticWndProc( HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam )
{
switch( uMsg )
{
case WM_PAINT:
{
...
}
case WM_SIZE:
{
...
}
}
}
ecc ecc.
Ecco tutte queste routine e anche altre di win le conosco e riesco a capacitarmi a scriverle e a farle funzionare tipico catturare il mouse il timer paint ecc.ecc
Una cosa che non riesco a capire è questa:
HRESULT WINAPI MyMessageHandler( PVOID pvUserContext,
DWORD dwMessageId,
PVOID pMsgBuffer )
{
switch( dwMessageId )
{
case RECEIVE:
{
break;
case messaggio:
{
break;
ecc.ecc.
Ecco questa sopra è una routine di eventi che nel momento in cui si logga un client il flusso del programma
entra come per magia in questa funzione... Ecco non riesco a capacitarmi come faccia il flusso a capire ed entrare in questa funzione.
E' una cosa che non riesco a capire e se dovessi rifarla da solo non so come far entrare il flusso in questa o altre routine simili
anche se fosse fatta da me.
Quindi la domanda per chi vuole aiutarmi è capire come strutturare una routine del genere di eventi.
Inoltre ho la necessità che quest'ultimo tipo di routine:
HRESULT WINAPI MyMessageHandler( PVOID pvUserContext,
DWORD dwMessageId,
PVOID pMsgBuffer )
{
ecc.ecc.
"HO INTENZIONE" di metterla in una dll/lib.
In definitiva devo far in modo di catturare l'evento, tipico dell'ultima routine, non nei cpp visibili appunto all'utente ma in una dll che dovrei implementare.
E' possibile...??...fare questo in una dll?? e continuare a processare tale routine di eventi dal main.cpp??
Ecco questa sopra è una routine di eventi che nel momento in cui si logga un client il flusso del programma
entra come per magia in questa funzione... Ecco non riesco a capacitarmi come faccia il flusso a capire ed entrare in questa funzione. perché qualcuno la chiama...? :fagiano:
se vuoi sapere chi la chiama osserva il call stack in fase di debug.
E' una cosa che non riesco a capire e se dovessi rifarla da solo non so come far entrare il flusso in questa o altre routine simili. le chiami :fagiano:
E' possibile...??...fare questo in una dll?? dal momento che chiamare una funzione che sta in una DLL (e in generale in un altro modulo) è possibile, con semplici passaggi... :fagiano:
perché qualcuno la chiama...? :fagiano:
se vuoi sapere chi la chiama osserva il call stack in fase di debug.
le chiami :fagiano:
dal momento che chiamare una funzione che sta in una DLL (e in generale in un altro modulo) è possibile, con semplici passaggi... :fagiano:
si si ok... ma non ti sembra poco performante questo metodo di prelievi dati dalla funzione handler posta nella dll??:
//tutto in dll inizializzazioni e variabili
HRESULT WINAPI MyMessageHandler( PVOID pvUserContext,
DWORD dwMessageId,
PVOID pMsgBuffer )
{
a=1;
...
}
poi da codice "chiamante" non è che si và a chiamare la HRESULT WINAPI posta nella dll ma si può prenderne i valori chiamando una funzione, che ne sò:
//nella dll
Ritorna valori()
{
return a;
}
nella dll che ritorna a=1 nel main.cpp chiamante.
questo metodo mi sembra non performante!!
questo metodo mi sembra non performante!!Guarda che le funzioni in una DLL vanno esportate se devono essere visibili dall'esterno!
Con VC++ si mette:
__declspec(dllexport) HRESULT WINAPI MyMessageHandler (....) { .... }
(l'esportazione si può fare anche usando un file .DEF)
Se un eseguibile ha tra le sue dipendenze la DLL, una volta che il sistema ha caricato la DLL e risolto gli indirizzi, cambia ben poco se la tua funzione è nell'eseguibile o nella DLL!
Guarda che le funzioni in una DLL vanno esportate se devono essere visibili dall'esterno!
Con VC++ si mette:
__declspec(dllexport) HRESULT WINAPI MyMessageHandler (....) { .... }
(l'esportazione si può fare anche usando un file .DEF)
Se un eseguibile ha tra le sue dipendenze la DLL, una volta che il sistema ha caricato la DLL e risolto gli indirizzi, cambia ben poco se la tua funzione è nell'eseguibile o nella DLL!
...e io che esportavo solo funzioni...
aspetta fammi capire:
HRESULT WINAPI MyMessageHandler c'è l'ho nella dll.
case okay:
{
contatore=0;
}
ora dal main.cpp devo prelevare contatore che vale 0 come punto dal main.cpp contatore (che vale 0) nel case okay posto in MyMessageHandler che stà nella dll??
senza fare una funzione per il prelievo delle variabili come scritto sopra che sarebbe un suicidio di programmazione??
ora dal main.cpp devo prelevare contatore che vale 0 come punto dal main.cpp contatore (che vale 0) nel case okay posto in MyMessageHandler che stà nella dll??
Che cavolo hai detto?
ora dal main.cpp devo prelevare contatore che vale 0 come punto dal main.cpp contatore (che vale 0) nel case okay posto in MyMessageHandler che stà nella dll??
senza fare una funzione per il prelievo delle variabili come scritto sopra che sarebbe un suicidio di programmazione??Ok ... la tua esposizione non è chiarissima ma ora ho capito: tu vuoi che la variabile 'contatore' sia direttamente visibile all'eseguibile.
Io prima avevo capito che il tuo problema era esportare le funzioni ... chiedo scusa. :doh:
Comunque si può fare: basta semplicemente esportare la variabile dalla DLL. Una cosa del tipo:
__declspec(dllexport) int contatore;
Tieni presente (ma credo che tu lo sappia già) che ogni processo che carica la DLL ha una sua copia della sezione dati della DLL. Quindi il processo A vede una variabile 'contatore' e il processo B vede un'altra variabile 'contatore'.
Tecnicamente si potrebbe anche creare una sezione "shared" all'interno della DLL in modo che tutti gli eseguibili che caricano la DLL vedano una unica variabile 'contatore' ma a te probabilmente non serve.
Ok ... la tua esposizione non è chiarissima ma ora ho capito: tu vuoi che la variabile 'contatore' sia direttamente visibile all'eseguibile.
Io prima avevo capito che il tuo problema era esportare le funzioni ... chiedo scusa. :doh:
Comunque si può fare: basta semplicemente esportare la variabile dalla DLL. Una cosa del tipo:
__declspec(dllexport) int contatore;
Tieni presente (ma credo che tu lo sappia già) che ogni processo che carica la DLL ha una sua copia della sezione dati della DLL. Quindi il processo A vede una variabile 'contatore' e il processo B vede un'altra variabile 'contatore'.
Tecnicamente si potrebbe anche creare una sezione "shared" all'interno della DLL in modo che tutti gli eseguibili che caricano la DLL vedano una unica variabile 'contatore' ma a te probabilmente non serve.
bhè grazie andbin...
dunque nella dll:
__declspec(dllexport) int contatore;
stessa cosa nell'.h "del chiamante", intendo la funzione.
la domanda è come prendo contatore? Scusa ma non sto al pc ora per fare delle prove.
nel "chiamante" come prendo contatore?
tipo come richiamando una funzione (quindi nel def metto una sorta di funzione chiamante) oppure tramite un ->
ciao=contatore(); //tipo funziione
oppure
ciao="?"->contatore;
... scusa ma non sto in postazione e stò scrivendo una marea di ca@@te... ma tu hai capito!!
la domanda è come prendo contatore?Nella DLL:
__declspec(dllexport) int contatore;
Nella applicazione (nel header o dove vuoi):
__declspec(dllimport) int contatore;
Poi la usi come una qualunque altra variabile:
printf ("%d\n", contatore);
contatore = 12;
Nella DLL:
__declspec(dllexport) int contatore;
Nella applicazione (nel header o dove vuoi):
__declspec(dllimport) int contatore;
Poi la usi come una qualunque altra variabile:
printf ("%d\n", contatore);
contatore = 12;
andbin... et voilà...
devo ancora testare... se ho problemi ti faccio sapere.
Alle volte faccio cose geniali altre volte riesco a stupire con cose "banali" e ovvie...e và bhè!
grazie andbin ti faccio sapere.
andbin
ho provato e funziona alla grande.
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.