2011-08-22 10 views
6

Ho un'applicazione .NET che deve essere in grado di rilevare quando una finestra specifica ottiene e perde lo stato attivo. La finestra specifica a cui sono interessato appartiene a un'altra applicazione di cui non ho alcun controllo, sebbene io abbia l'handle di Windows..NET/Win32 - evento per rilevare quando viene attivata una finestra di un'altra app

Sono davvero dopo il modo migliore per affrontare questo. Finora, posso vedere 2 possibilità:

  1. Utilizzo di una chiamata Win32 su un timer per monitorare eventuali cambiamenti di stato. Non eccezionale, in quanto corre il rischio di perdere i cambiamenti di stato, ad es. se la finestra diventa attiva allora inattiva nell'intervallo di tempo
  2. Utilizzo di ganci (SetWindowsHookEx) per intercettare i messaggi nella finestra. Sembra che dovrebbe funzionare, ma preoccupato che a) gli hook a livello globale non funzionino con il codice .NET, quindi dovrebbe essere nativo eb) potrebbe essere considerato attività di tipo virus/keylogger, quindi bloccato dal sistema operativo?

Sono sicuro che ci sono anche altre opzioni, in tal caso, mi piacerebbe sentirle!

risposta

6

È probabile che il modo più semplice sia utilizzare SetWinEventHook, in ascolto di eventi EVENT_SYSTEM_FOREGROUND. È necessario utilizzarlo con il flag WINEVENT_OUTOFCONTEXT per utilizzarlo in .net: quando si utilizza questo flag, Windows indirizza le notifiche al proprio processo, quindi non è necessaria una DLL non gestita separata. Si noti tuttavia che il codice che chiama questo metodo deve avere un ciclo di messaggi in esecuzione.

Breve nota su come questo si riferisce all'articolo citato nell'altra risposta: quell'articolo si concentra sull'API SetWindowsHook. SetWinEventHook è un'API separata, ma si utilizza la stessa tecnica per impostare la chiamata P/Invoke e per configurare un delegato per la richiamata, sebbene si noti che le due API utilizzano parametri diversi sia nelle chiamate API che nelle callback . Il vantaggio principale che SetWinEventHook ha su SetWindowsHook è che per alcuni tipi di hook, SetWindowsHook richiede l'uso di una DLL non gestita separata, che non è possibile eseguire direttamente in .net. SetWinEventHook tuttavia consente il tipo di callback, utilizzando una DLL non gestita separata o notificando il processo originale senza richiedere una DLL, quindi è più .net-friendly.

+2

Perfetto: questo è quasi esattamente quello che stavo cercando. Sembra esserci un caso d'angolo in cui (a volte) la massimizzazione di una finestra precedentemente ridotta a icona non attiva EVENT_SYSTEM_FOREGROUND per quella finestra, quindi anche l'ascolto di EVENT_SYSTEM_MINIMIZEEND lo circonda. Grazie, risposta impressionante –

+0

Il vincolo del loop del messaggio non è stato un problema per me perché stavo correndo un'applicazione WPF. Per chiunque desideri fare lo stesso, ma con un'app Console (nessun loop di messaggi per impostazione predefinita), questo articolo è valido (cerca "Gestione dei messaggi nelle app della console" "Stephen Toub" se il collegamento è interrotto) - http: // msdn .microsoft.com/en-us/magazine/cc163417.aspx –

0

Ecco un fantastico articolo sull'implementazione degli hook di Windows in .NET dalla rivista MSDN: Windows Hooks in the .NET Framework.

Per quanto riguarda la seconda preoccupazione, non ho mai sentito parlare di antivirus che rilevano queste chiamate API come comportamento spyware.

Spero che aiuti!

Problemi correlati