2008 MFC и темы?

Question

Я читал эту тему / сообщение: https://stackoverflow.com/questions/262298/windows-c-ui-technology

, и мне также интересно узнать о среде .NET UI. В частности - до того, как в .NET появилась поддержка последовательных портов (я не могу поверить, что они исключили это из первого выпуска .NET), я был вынужден использовать MFC для приложения. Я не был разработчиком графического пользовательского интерфейса и быстро обнаружил, что теряю голову из-за ужасной нехватки способности MFC хорошо играть с другими потоками в моем приложении - например, вызов метода управления пользовательским интерфейсом для обновления данных или выполнения других действий из другого потока. Большинство из этих проблем были решены, но код приложения слишком сложен для обмена сообщениями и тому подобного, чтобы справиться с недостатками MFC.

Итак, мой вопрос: есть ли в «Новой и улучшенной» mfc поддержка потоков - то есть, если я вызову какой-либо элемент управления mfc для объекта графического интерфейса из другого потока, произойдет ли сбой / рвота, как старый mfc, или он может играть в реальный мир?

EDIT

Чтобы уточнить - я понимаю беспокойство по поводу манипулирования с графическим интерфейсом в отдельных потоках, но я надеялся, что вместо того, чтобы программист создавал пользовательские сообщения и отправлял их из рабочих потоков, - что среда графического интерфейса будет делать все это работать для меня, и я мог бы просто вызывать методы объекта из других потоков. Возможно, на это слишком много надежды, особенно если потоки еще не являются частью языковой спецификации.

Answer 1

Это не ограничение MFC - это дизайн Windows. Вы не можете начать отправку сообщений на произвольные элементы управления из случайных других потоков. (Ну, иногда вы можете, но вам нужно знать, что вы делаете.) Это в равной степени верно в мире .NET - когда элемент управления виден, вам нужно использовать делегата для его обновления, чтобы действие обновления происходит в правильном потоке.

В целом, я бы сказал, что из опыта почти всегда лучше иметь только один поток, обрабатывающий графический интерфейс в приложении, и сделать оставшиеся потоки чисто рабочими. Взаимодействие нескольких потоков с GUI приводит к безумию, пытающемуся отследить происходящее.

EDIT

Короткий ответ на оригинальный вопрос, боюсь, «нет»: не было фундаментальной переделки того, как взаимодействуют потоки, MFC и Windows. На данный момент, поскольку MFC едва ли является приоритетом в Microsoft, я не ожидаю, что это изменится.

Answer 2

Базовая архитектура MFC в новой версии практически не изменилась. Если вы ранее не были довольны поддержкой потоков, то можно с уверенностью сказать, что вы все равно не будете. Я согласен с тем, что сказал DavidK - это неотъемлемая проблема, с которой приходится сталкиваться всем фреймворкам. Основная причина того, что MFC не предоставляет много помощи для многопоточности, почти наверняка, потому что она была первоначально введена в 1992 году для 16-битной Windows. В настоящее время Windows не поддерживает многозадачность и фактически является однопоточным.

Answer 3

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

Вы можете использовать рабочие потоки, чтобы помочь, но сохраняйте работу вашего GUI в основном потоке.

Вы обнаружите, что большинство оконных инструментов также являются однопоточными (поскольку, как правило, их использует один пользователь :)), те, которые не являются более сложными, чем они стоят.

Answer 4

использовать .NET GUI и поток, основной код приложения в MFC DLL.

позвоните через c # делегат