나는 Outlook 추가 기능을 작성하여 스팸을 걸러 냈습니다. 문제는 추가 기능이 메시지 처리 작업을 수행하고 특히 처리 중이거나 읽는 큰 첨부 파일이있을 때 많은 시간이 걸리며 이로 인해 주요 Outlook UI가 취소됩니다. 반응 형이며 사용자는 UI로 아무 것도 할 수 없습니다.Outlook 추가 기능이 느려져 Outlook UI가 느려짐
Outlook UI가 정상적으로 유지되도록 추가 기능 처리를 실행하는 비동기 방식이 있습니까?
추가 기능은 각 메시지의 처리로 인해 많은 일을하므로 많은 시간이 걸립니다.
기본적으로 다른 프로그램과 마찬가지입니다. 주 스레드 외부에서 수행해야 할 작업 (예 : 다른 스레드 생성) 하지만 Outlook 관련 API 또는 프레임 워크는 없습니다.
예외 처리에 대해서는 특별히주의해야합니다. 스레드에서 벗어나는 처리되지 않은 예외는 가장 이상한 결과를 가질 수 있습니다 (대부분의 경우 Outlook은 단순히 중단됩니다).
또한 가능한 한 처리 스레드 내에서 Outlook 개체 모델 액세스를 피하거나 최소한 제한해야합니다.
마지막으로 확실한 것은 COM 관련 함수를 직접 또는 간접적으로 사용하는 경우 새 스레드에 대해 CoInitializeEx/CoUninitialize을 명시 적으로 호출해야한다는 것입니다.
다른 스레드를 만드는 것은 Outlook API에서 많은 시간을 소비하는 경우 도움이되지 않습니다. Outlook의 스레딩 모델로 인해 다른 스레드에서 개체 모델에 액세스하면 호출이 주 스레드로 마샬링되어 UI가 여전히 고정되어 있고 백그라운드 스레드가 차단되고 있음을 의미합니다.
대부분의 작업이 Outlook 개체 모델을 만지지 않도록하는 데 소비되는 경우 저장 한 첨부 파일을 처리하기 위해 별도의 작업자 스레드 (또는 스레드 풀)가 크게 개선 될 것입니다 .
정확하게 - 어떻게 백그라운드 스레드에 작업을 배포하든 관계없이, Outlook Object Model은 호출을 UI 스레드 및 블록으로 직렬화합니다. (일부 비주얼 스튜디오 API는 꽤 유사합니다. 일단 가볍게 사용하면 가볍게 사용하면 UI가 차단됩니다. 누군가 알고 있다면 기쁠 것입니다. 해결 방법 ... –
예. 알아요. 그래서 각 항목을 처리 할 새로운 Win32 스레드를 생성해야합니다. 즉,이 기능은 COM 추가 기능에서 수행해야합니다. C++로 작성되었습니다. 이 스레드를 생성하는 데 대한 팁은 다음과 같이하십시오. Thnaks. – user61862
그 생각이 맞습니다. 그 밖의 어디에서 일어 났습니까? 항목 당 스레드가 반드시 필요한 것은 아닙니다. 그것은 당신에게 전적으로 달려 있습니다. 나는 C++ 코더가 아니므로 다중 언어 프로그래밍에 대한 구체적인 내용을 줄 수는 없다. (CreateThread API에 대한 막연한 물결을 제외하고) –