Change Details

Sending without blocking Outlook so that it is unresponsive means that we have to cancel the original send, do encrypt / sign and then invoke the send once the crypto is done. This crashes in the workaround for T3656 and it has been reported by at least one user of the Gpg4win-3.1.0-beta22 that it crashes for him without the code for T3656. While this is very stable for me and for other testers of the beta, I can confirm a very similar crash to the debug output sent by that user when I change the timing of our send invocation. This leads me to the conclusion that our async sending might be less stable then the sending in which we block outlook in the send event to do crypto. As we currently need stability over "niceness" I'll disable the async sending for now until we might figure out how to improve the timing of the send invocation so that outlook does not crash.

Sending without blocking Outlook so that it is unresponsive means that we have to cancel the original send, do encrypt / sign and then invoke the send once the crypto is done. This crashes in the workaround for T3656 and it has been reported by at least one user of the Gpg4win-3.1.0-beta22 that it crashes for him without the code for T3656. While this is very stable for me and for other testers of the beta, I can confirm a very similar crash to the debug output sent by that user when I change the timing of our send invocation. This leads me to the conclusion that our async sending might be less stable then the sending in which we block outlook in the send event to do crypto. As we currently need stability over "niceness" I'll disable the async sending for now until we might figure out how to improve the timing of the send invocation so that outlook does not crash. As this is disabled now I've changed the title and marked is as wish to enable it again.

Sending without blocking Outlook so that it is unresponsive means that we have to cancel the original send, do encrypt / sign and then invoke the send once the crypto is done. This crashes in the workaround for T3656 and it has been reported by at least one user of the Gpg4win-3.1.0-beta22 that it crashes for him without the code for T3656. While this is very stable for me and for other testers of the beta, I can confirm a very similar crash to the debug output sent by that user when I change the timing of our send invocation. This leads me to the conclusion that our async sending might be less stable then the sending in which we block outlook in the send event to do crypto. As we currently need stability over "niceness" I'll disable the async sending for now until we might figure out how to improve the timing of the send invocation so that outlook does not crash. As this is disabled now I've changed the title and marked is as wish to enable it again.