来自 ShareTarget second window 的代码编组异常

Question

我遇到了一些代码，当从 ShareTarget 合同创建的第二个 window 调用时，我的一些代码显然很困难（当您与应用程序共享某些内容时，它会在一个小的独立窗口中打开window).

到目前为止，这是我的代码：

// Blur and resize the image to get the average HSL color
// Assume that stream is an IRandomAccessStream pointing to valid image data
HslColor hslMean;
using (RandomAccessStreamImageSource imageProvider = new RandomAccessStreamImageSource(stream))
using (BlurEffect blurEffect = new BlurEffect(imageProvider) { KernelSize = 256 })
{
    Color mean = await DispatcherHelper.GetFromUIThreadAsync(async () =>
    {
        WriteableBitmap
            blurred = new WriteableBitmap((int)decoder.PixelWidth, (int)decoder.PixelHeight),
            result = await blurEffect.GetBitmapAsync(blurred, OutputOption.Stretch),
            resized = result.Resize(1, 1, WriteableBitmapExtensions.Interpolation.Bilinear);
        return resized.GetPixel(0, 0);
    });
    hslMean = mean.ToHsl();
}

注意：DispatcherHelper.GetFromUIThreadAsync 方法只检查线程对UI 线程的访问，如果需要它会将代码调度到CoreDispatcher 使用 CoreApplication.MainView.CoreWindow.Dispatcher.

获得的对象

Problem: this code works 100% fine if my app is already open, as at that point that CoreDispatcher object has already been created by previous calls to that DispatcherHelper class, so the method just uses the stored dispatcher to schedule the work and it works fine. But, if the app is closed when the ShareTarget window is opened (so that DispatcherHelper has to create the dispatcher for the first time) the CoreApplication.MainView.CoreWindow line throws an exception. A very weird one:

COMException: A COM call to an ASTA was blocked because the call chain originated in or passed through another ASTA. This call pattern is deadlock-prone and disallowed by apartment call control. A COM call (IID: {638BB2DB-451D-4661-B099-414F34FFB9F1}, method index: 6) to an ASTA (thread 10276) was blocked because the call chain originated in or passed through another ASTA (thread 4112). This call pattern is deadlock-prone and disallowed by apartment call control.

因此，我需要一种方法使该方法即使在从不同 windows 调用时也可靠。我尝试了不同的选择：

#1：只是调用该代码而不分派到不同的线程，理论上我此时应该在 UI 线程上 ---> FAIL（应用程序调用了为不同线程编组的接口。（HRESULT 异常：0x8001010E (RPC_E_WRONG_THREAD)））

#2：手动调用 CoreApplication.MainView.CoreWindow.Dispatcher 以分派该代码块 ---> FAIL（我觉得很奇怪COMException如上）

#3：手动使用 CoreApplication.MainView.Dispatcher 分派代码块（因为它是 .CoreWindow 产生异常的部分）---> 失败（COMException：找不到项目）

#4：使用 CoreApplication.GetCurrentView().CoreWindow.Dispatcher、CoreApplication.GetCurrentView().Dispatcher、Window.Current.CoreWindow.Dispatcher 和 Window.Current.Content.Dispatcher 来安排该代码 ---> 失败（又是错误的线程，我得到了通常的编组异常）

所有这些编组异常都在result = await blurEffect.GetBitmapAsync(blurred, OutputOption.Stretch)行抛出，所以我怀疑这可能与Lumia Imaging SDK有关。我的意思是，我很确定我实际上在 UI 线程上，否则我不会设法创建 WriteableBitmap class 的实例，对吗？

Why is it that I can create WriteableBitmap objects (and they need to be created on the UI thread as far as I know), but that GetBitmapAsync method from the Lumia SDK always throws that marshalling exception? I'm using it everywhere in my app without any problems, why is it that it just won't work from the ShareTarget window? Is there anything I need to do?

感谢您的帮助！

Answer 1

看起来这是 Lumia Imaging SDK 中的一个错误（最初是为 WP8.1 编写的，没有多个 windows/dispatchers），所以除非从与主应用程序关联的调度程序 window（当然只有当 ShareTarget window 弹出时应用程序在后台打开时才能检索），它只会失败。

此时唯一的解决方案是用一些不依赖于该特定库的其他代码替换对 Lumia SDK 的调用（例如，在这种情况下，可以从WriteableBitmap 对象并手动计算平均颜色）。

来自 ShareTarget second window 的代码编组异常

Marshalling exception with code from the ShareTarget second window

c#

xaml

windows-runtime

uwp

lumia-imaging-sdk