Manipolazione C # Console App + Evento

Question

Ciao a tutti. Sto cercando di vedere sulla gestione degli eventi in un'applicazione console. Io preferirei non usare WinForms silenziosi (anche se capisco che questo è un modo) per farlo. Ho letto più di una domanda simile e la sua risposta. Vedere testo di risposta al di sotto ( link ):

  

Il requisito fondamentale di un thread STA   è che ha bisogno di eseguire un messaggio   pompa. In Windows Form, è possibile utilizzare   Application.Run. Oppure si potrebbe scrivere   la pompa messaggio a mano, utilizzando   user32! GetMessage & DispatchMessage.   Ma è probabilmente più facile da usare il   uno in WinForms o WPF.

Ciò che la struttura di base di un programma che utilizza "user32 -> GetMessage" & "user32 -> DispatchMessage"

Answer 1

Vedere l'argomento "che utilizzano i messaggi e le code di messaggi" in MSDN (sotto Win32 e COM Sviluppo> Interfaccia utente> di Windows User Experience> gestione Windows> Finestre Interfaccia utente> Windowing> Messaggi e code di messaggi, avrete probabilmente bisogno di prendere uno sguardo alle altre articoli e campioni nella stessa sezione). Rapido riepilogo, omettendo la gestione degli errori e utilizzando la sintassi C piuttosto che C # per i motivi discussi qui di seguito:

RegisterClass(...);
CreateWindow(...);
ShowWindow(...);  // probably not in your case
while (GetMessage(&msg, NULL, 0, 0)) {
  TranslateMessage(&msg);
  DispatchMessage(&msg);
}

Come si può vedere dalla boilerplate messa a punto della finestra, questa si basa ancora su "finestre silenti", sia pure creato e il messaggio-pompato tramite l'API Win32 piuttosto che attraverso WinForms. Quindi non sta guadagnando davvero nulla da fare in questo modo. Quindi il mio sentimento non c'è più molto senso tradurre questa roba in C # -. Se l'unica soluzione al vostro problema è una finestra invisibile, si può anche utilizzare un invisibile Windows Form e tutti gli involucri amichevoli che vengono con quella piattaforma

Tuttavia, se non si sta usando un Windows Form controllano come il manifesto della questione legata, allora si può tranquillamente utilizzare gli eventi .NET in un'applicazione console. La limitazione a STA e la necessità di una pompa messaggio è specifico per la ricezione di eventi da WinForms e controlli ActiveX come il browser web (o messaggi da Win32 HWNDs, anche se questo non significa necessariamente richiede STA).

Answer 2

Quali eventi tipo vuoi gestire? Impostazione di una pompa messaggio vi permetterà di elaborare i messaggi API di Windows. Ma dal momento che si tratta di una console app, non riesco a pensare di qualsiasi messaggio API di Windows che potrebbero essere di interesse.

Si tende a pensare di "eventi" come associata a messaggi di Windows perché i controlli in Windows Form risponde all'input dell'utente utilizzando i delegati EventHandler, che sono chiamati in risposta ai messaggi API di Windows. Tuttavia, non c'è ragione per cui non è possibile utilizzare delegati in una console app; e non avete bisogno di una pompa di messaggio. È anche possibile utilizzare il delegato EventHandler, benche sembrerà fuori luogo, perché non sarà resonding ai messaggi API di Windows.

Naturalmente ci sono altri tipi di "eventi" che si può essere interessati a. Il tipo più comune di scenario evento che coinvolge una console app è quello di attendere l'input dalla console (stdin). È anche comune bloccare su un WaitHandle o altro oggetto di sincronizzazione se ci sono più thread in uso. Entrambi questi casi potrebbe essere considerato un tipo di gestione degli eventi.

Se si crea una finestra nascosta (una pratica onorata di tempo), è comunque necessario un messaggio di Windows per rispondere a. Quindi la domanda è: fino a che, oa chi, stai cercando di rispondere

?

Answer 3

Vorrei utilizzare il metodo Application.Run. Non credo che si crea una finestra nascosta automaticamente, pompe solo i messaggi, che è ciò che è necessario per soddisfare il requisito STA.

Scrivere un proprio pompa di messaggio utilizzando PInvoke non offre alcun vantaggio e riferimento System.Windows.Forms non è molto di un onere, perché è già su tutte le macchine che si possono verificare.