使用ShareTarget第二个窗口中的代码进行编组例外

当我从ShareTarget合同创建的第二个窗口中调用时，我显然挣扎了一些代码（当您与应用程序共享某些内容时，它会打开一个小的独立窗口）。使用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对象，与获得CoreApplication.MainView.CoreWindow.Dispatcher。

问题：此代码的工作100％的罚款，如果我的应用程序已经打开，因为在那时，CoreDispatcher对象已经由先前调用到DispatcherHelper类创建的，因此该方法只使用存储的调度安排工作，它工作正常。但是，如果在打开ShareTarget窗口时关闭应用程序（因此DispatcherHelper必须首次创建调度程序），CoreApplication.MainView.CoreWindow行会引发异常。一个很奇怪的一个：

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

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

＃1：只要调用代码不指派给不同的线程，因为在理论上我应该是在UI线程在这一点上--->FAIL（应用程序称为一个接口，被编组为一个不同的线程。（从HRESULT异常：0x8001010E（RPC_E_WRONG_THREAD）））

＃2：手动调用CoreApplication.MainView.CoreWindow.Dispatcher分派该代码块--->FAIL（我得到的怪异COMException如上所述）

＃ 3：手动使用CoreApplication.MainView.Dispatcher分派码块（因为它是那产生异常的.CoreWindow一部分）--->FAIL（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类的实例，对吧？

为什么我可以创建WriteableBitmap对象（他们需要在UI线程上创建，据我所知），但是从的Lumia的SDK，GetBitmapAsync方法总是抛出异常编组？我在我的应用程序中的任何地方都没有任何问题地使用它，为什么它不能从ShareTarget窗口中运行？有什么我需要做的吗？

感谢您的帮助！

来源

2017-05-31 Sergio0694

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

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

来源

2017-06-01 17:12:11 Sergio0694

@清道夫是的，我只是在等待接受功能可用，因为我发布的解决方案不到48小时后，最初的问题，感谢提醒！ – Sergio0694

使用ShareTarget第二个窗口中的代码进行编组例外

回答

相关问题