使用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第二個窗口中的代碼進行編組例外

回答

相關問題