надстройка Outlook, замедляющая пользовательский интерфейс Outlook

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

Существует ли асинхронный способ запуска обработки надстройки, чтобы пользовательский интерфейс Outlook оставался в порядке.

Надстройка делает много вещей из-за обработки каждого сообщения и, следовательно, занимает много времени.


person user61862    schedule 07.02.2009    source источник


Ответы (2)


Создание другого потока не поможет вам, если основная часть времени тратится на API Outlook. Из-за многопоточной модели в Outlook доступ к объектной модели из другого потока приведет к маршаллингу вызова в основной поток, что означает, что теперь ваш пользовательский интерфейс все еще заморожен, а фоновый поток блокируется.

Если большая часть работы тратится на действия, не затрагивающие объектную модель Outlook, вы, вероятно, заметите значительное улучшение, выделяя отдельный рабочий поток (или пул потоков) для обработки сохраненных вложений.

person Josh    schedule 09.12.2009
comment
Точно - независимо от того, как вы распределяете работу по фоновым потокам, объектная модель Outlook будет сериализовать вызовы обратно в поток пользовательского интерфейса и блокировать :(. Кстати, некоторые API Visual Studio очень похожи - если вы используете их более чем легко, они блокируют пользовательский интерфейс , Я был бы рад, если бы кто-нибудь знал об обходном пути... - person Tomáš Kafka; 07.01.2010

В принципе, как и в любой другой программе. Если вам нужно сделать что-то вне основного потока, сделайте это (т.е. создайте другой поток). Однако API или инфраструктура, специфичная для Outlook, отсутствует.

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

Кроме того, по возможности следует избегать или, по крайней мере, резко ограничивать доступ к объектной модели Outlook из потока обработки.

Наконец, еще одна вещь, в которой вы должны убедиться, это то, что вы явно вызываете CoInitializeEx / CoUninitialize специально для вашего нового потока, если он каким-либо образом прямо или косвенно использует функции, связанные с COM.

person Oliver Giesen    schedule 07.02.2009
comment
Да, я понял. Так что мне по существу нужно создать новый поток Win32, который будет обрабатывать каждый элемент? то есть это должно произойти в надстройке COM, я так понимаю? Он написан на С++. Любые дополнительные советы по спауну этой темы, пожалуйста :-) Tnaks. - person user61862; 08.02.2009
comment
Это идея, да. Где бы еще это случилось? Однако вам не обязательно нужен поток для каждого элемента. Это полностью зависит от вас. Я сам не кодер на С++, поэтому не могу дать вам никаких подробностей о многопоточном программировании на этом языке (кроме неопределенной волны в сторону CreateThread API) - person Oliver Giesen; 08.02.2009