Question

我遇到的一些代码很困难，从ShareTarget合约创建的第二个窗口调用时显然很挣扎（当你向应用程序分享内容时，它会在一个小的独立窗口中打开）。

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

// 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对象，该对象是使用{{{ 1}}。

问题：如果我的应用已经打开，此代码可以100％正常运行，因为之前调用CoreApplication.MainView.CoreWindow.Dispatcher已经创建了CoreDispatcher个对象class，所以该方法只使用存储的调度程序来安排工作，它工作正常。但，如果在打开ShareTarget窗口时关闭应用程序（以便DispatcherHelper必须首次创建调度程序），DispatcherHelper行会抛出异常。一个非常奇怪的：


CoreApplication.MainView.CoreWindow：     对ASTA的COM调用被阻止，因为调用链起源于或通过另一个ASTA。这种呼叫模式容易出现死锁，并且不受公寓呼叫控制的限制。     由于调用链起源于或通过另一个ASTA（线程4112），因此阻止了对ASTA（线程10276）的COM调用（IID：{638BB2DB-451D-4661-B099-414F34FFB9F1}，方法索引：6）。这种呼叫模式容易出现死锁，并且不受公寓呼叫控制的限制。

所以，即使从不同的窗口调用，我也需要一种方法使该方法可靠。我尝试了不同的选择：

＃1 ：只调用该代码而不调度到不同的线程，理论上我应该在UI线程上这一点---＆gt; FAIL （该应用程序称为为不同线程编组的接口。（HRESULT异常：0x8001010E（RPC_E_WRONG_THREAD）））

＃2 ：手动调用COMException以分发该代码块---＆gt; 失败（我得到上面提到的那个奇怪的CoreApplication.MainView.CoreWindow.Dispatcher）

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

＃4 ：使用COMException，CoreApplication.GetCurrentView().CoreWindow.Dispatcher，CoreApplication.GetCurrentView().Dispatcher和Window.Current.CoreWindow.Dispatcher来安排该代码---＆gt; 失败（错误的主题，我得到通常的编组异常）

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

为什么我可以创建WriteableBitmap个对象（据我所知，它们需要在UI线程上创建），但Lumia SDK中的WriteableBitmap方法始终会抛出编组例外？我在我的应用程序中随处使用它没有任何问题，为什么它只是不能从ShareTarget窗口工作？有什么我需要做的吗？

感谢您的帮助！

Answer 1

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

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

使用ShareTarget第二个窗口

1 个答案: