Newsgroup: it.comp.lang.delphi
Titolo: Ah... questi hook... codice che viene erroneamente(?) richiamato piu' volte!

Dunque, la saga degli hooks continua.... <g>
Questa volta ci si mette di mezzo una cosa curiosa, di cui non riesco a
tracciare la cagione.
Ecco il codice "incriminato":
function CBTProc(code: Integer; wparam: WPARAM; lparam: LPARAM): LRESULT
stdcall;
begin
  if Code > 0 then
  begin
    if Not WinProcInstalled then
    begin
      LastProc := SetWindowLong( Window,GWL_WNDPROC,LongInt( @WndProc ) );
      if LastProc = 0 then
      begin
        MessageBox( Window,GetLastErrorString( GetLastError ),'Hook
proc',MB_OK );
      end;
      WinProcInstalled := True;
      MessageBox( Window,'Hook installed','Controller',MB_OK );
    end;
  end;
  Result := CallNextHookEx( WH_CBT,code,wparam,lparam );
end;
Il problema è che in ogni caso, anche se non dovesse andare a buon fine, la
variabile WinProcInstalled dovrebbe essere impostata a true, cosa che invece
sembra non succedere.
La cosa interessante è che dopo alcune chiamate, il problema si risolve...
cioè la
window proc NON viene installata, ma il flusso dell'esecuzione riprende ad
essere
come dovrebbe... morale: mettendo un breakpoint all'inizio della procedura
di
sopra, esso non vi arriva mai, quindi non posso vedere che flusso segue
quella
dannata routine!
Qualche idea su come fare il debug di quell'affare o quale potrebbe essere
il
problema?
Ciao,
Andrea

Prova ad eliminare le procedure MessageBox(..), un hook deve essere il piu' veloce possibile.
Per visualizzare i messaggi creati un evento messaggio personalizzato (Es WM_MioMes = WM_USER + 10;) e gestiscilo dalla
form principale.
--
Ciao,
David (
www.utilityweb.net
)

 (Es WM_MioMes = WM_USER + 10;) e gestiscilo dalla form principale.
Quindi, dici, gestirlo dalla mia APP che carica la DLL anziche' da dentro la
DLL stessa? Uhm, potrebbe anche andare... boh, provo domani!
Ciao,
Andrea




 sembra non succedere.
Controlla il valore della variabile direttamente nella HookProc.
Anche se tutta la DLL viene iniettata ricorda che il sistema operativo
richiama *solo* la hook procedure.
--
- Carlo -
"Imparare senza riflettere o riflettere senza imparare non vi porta alla
buona comprensione" Confucio
ps: scusate per l'altro messaggio ma è partito un invio! ;-)

 richiama *solo* la hook procedure.
Mi sta venendo un dubbio... ma se io predispongo tutto, nel momento in cui
la hook procedure viene chiamata, la DLL nell'altro processo NON E'
inizializzata,
dunque devo trovare un sistema per risolvere la cosa... giusto?
Ma se non "threadvarizzo"( gh, che brutto <g> ) le variabili, esse
dovrebbero
essere condivise a quello che ricordo. O sbaglio?
Ciao,
Andrea

 dovrebbero essere condivise a quello che ricordo. O sbaglio?
Condivise tra chi? Se parli di uno stesso spazio di indirizzamento si, se
parli di spazi di indirizzamento diverso no (a meno di non aver usato
particolari tecniche ipc)


 aver usato particolari tecniche ipc)
Parlo di due istanze della stessa DLL, la quale dovrebbe essere solo
referenziata da due handles diversi, ma essere sempre e solo una,
avendo separate solo le variabili in threadvar... o no?
Ciao,
Andrea

 avendo separate solo le variabili in threadvar... o no?
Dunque se la DLL è caricata per due volte nello stesso processo avrai due
aree dati ed una sola area codice (viene incrementato un reference counter).
Se parli di una stessa DLL caricata in più processi non condivide ne area
codice ne area dati con l'altra.
