Консольное приложение C # + обработка событий - PullRequest
4 голосов
/ 19 апреля 2009

Привет всем. Я пытаюсь узнать об обработке событий в консольном приложении. Я бы предпочел не использовать тихие WinForms (хотя я понимаю, что это один из способов) сделать это. Я перечитал похожий вопрос и ответ на него. См. Текст ответа ниже ( ссылка ):

Основное требование к резьбе STA это то, что нужно запустить сообщение насос. В Windows Forms вы можете использовать Application.Run. Или вы могли бы написать сообщение откачивать вручную, используя user32! GetMessage & DispatchMessage. Но, вероятно, проще использовать один в WinForms или WPF.

Какова основная структура программы, которая использует «user32 -> GetMessage» и «user32 -> DispatchMessage»?

Ответы [ 3 ]

3 голосов
/ 19 апреля 2009

См. Раздел «Использование сообщений и очередей сообщений» в MSDN (в разделе «Разработка для Win32 и COM»> «Интерфейс пользователя»> «Работа с Windows»> «Управление Windows»> «Интерфейс пользователя Windows»> «Работа с окнами»> «Сообщения и очереди сообщений»). посмотрите на другие статьи и образцы в том же разделе). Краткое резюме, исключая обработку ошибок и используя синтаксис C вместо C # по причинам, обсуждаемым ниже:

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

Как видно из шаблона настройки окна, он по-прежнему опирается на «тихие окна», хотя и создаваемые и прокачиваемые сообщениями через Win32 API, а не через WinForms. Таким образом, вы действительно ничего не получаете, поступая таким образом. Поэтому я чувствую, что нет смысла переводить этот материал на C # - если единственным решением вашей проблемы является невидимое окно, вы также можете использовать невидимую форму Windows и все дружественные оболочки, которые поставляются с этой платформой.

Однако, если вы на самом деле не используете элемент управления Windows Forms, такой как плакат связанного вопроса, тогда вы вполне можете использовать события .NET в консольном приложении. Ограничение в отношении STA и необходимость в прокачке сообщений характерны для получения событий от WinForms и элементов управления ActiveX, таких как WebBrowser (или сообщений от Win32 HWND, хотя для этого необязательно требуется STA).

0 голосов
/ 21 апреля 2009

Я бы использовал метод Application.Run. Я не думаю, что он автоматически создает скрытое окно, он просто качает сообщения, и это то, что вам нужно для удовлетворения требований STA.

Написание собственного почтового сообщения с использованием PInvoke не дает никаких преимуществ, и ссылки на System.Windows.Forms не являются обременительными, поскольку это уже на каждой машине, с которой вы можете столкнуться.

0 голосов
/ 19 апреля 2009

Какие события вы хотите обработать? Настройка рассылки сообщений позволит вам обрабатывать сообщения Windows API. Но так как это консольное приложение, я не могу думать о каких-либо сообщениях Windows API, которые были бы интересны.

Мы склонны считать «события» связанными с сообщениями Windows, поскольку элементы управления в приложении Windows Forms реагируют на ввод пользователя с помощью делегатов EventHandler, которые вызываются в ответ на сообщения Windows API. Однако нет причин, по которым вы не можете использовать делегатов в консольном приложении; и вам не нужен насос сообщений. Вы даже можете использовать делегат EventHandler, хотя он будет казаться неуместным, поскольку он не будет резонировать с сообщениями Windows API.

Конечно, есть другие виды «событий», которые могут вас заинтересовать. Наиболее распространенный тип сценария событий, включающий консольное приложение, - это ожидание ввода с консоли (stdin). Также обычно блокируют WaitHandle или другой объект синхронизации, если используется несколько потоков. Оба этих случая можно считать типом обработки событий.

Если вы создадите скрытое окно (проверенное временем), вам все равно потребуется сообщение Windows, чтобы ответить. Итак, вопрос в том, что или кому вы пытаетесь ответить?

...