在不同的 UI 线程中打印 DocumentViewer 的内容

发布于 2024-12-03 04:08:27 字数 2229 浏览 1 评论 0原文

在我的 WPF 应用程序中,我有一个特定的 Window,其中包含 DocumentViewer 等控件。

当此窗口打开并加载时,它会动态构建一个带有进度指示器的 FixedDocument,然后将其显示在 DocumentViewer 中。它有效,并且为了改善用户体验,我在其自己的线程中运行此窗口,以便主应用程序窗口在构建文档时仍然具有响应能力。

基于此网页的提示,我在一个新线程中打开窗口,如下所示:

public void ShowDocumentViewerWindow(params object[] data) {
    var thread = new Thread(() => {
        var window = new MyDocumentViewerWindow(new MyObject(data));
        window.Closed += (s, a) => window.Dispatcher.InvokeShutdown();
        window.Show();
        System.Windows.Threading.Dispatcher.Run();
    });
    thread.SetApartmentState(ApartmentState.STA);
    thread.Start();
}

到目前为止,我对这个设置很满意,但我刚刚遇到了一个问题。

MyDocumentViewerWindow 包含一个打印按钮,它引用内置的打印命令,针对 DocumentViewer:

<Button Command="Print" CommandTarget="{Binding ElementName=MyDocumentViewer}">Print</Button>

在我将窗口置于自己的线程中之前,这工作得很好。但现在,当我单击它时,应用程序崩溃了。 Visual Studio 2010 将上述代码中的以下行突出显示为崩溃位置,并显示消息“调用线程无法访问此对象,因为另一个线程拥有它。”:

System.Windows.Threading.Dispatcher.Run();

堆栈跟踪如下所示开始:

at System.Windows.Threading.Dispatcher.VerifyAccess()
at MS.Internal.Printing.Win32PrintDialog.ShowDialog()
at System.Windows.Controls.PrintDialog.ShowDialog()
at System.Printing.PrintQueue.GatherDataFromPrintDialog(PrintDialog printDialog, XpsDocumentWriter&amp;amp; writer, PrintTicket&amp;amp; partialTrustPrintTicket, PrintQueue&amp;amp; partialTrustPrintQueue, Double&amp;amp; width, Double&amp;amp; height, String jobDescription)
at System.Printing.PrintQueue.CreateXpsDocumentWriter(String jobDescription, PrintDocumentImageableArea&amp;amp; documentImageableArea)
at System.Windows.Controls.Primitives.DocumentViewerBase.OnPrintCommand()
at System.Windows.Controls.Primitives.DocumentViewerBase.ExecutedRoutedEventHandler(Object target, ExecutedRoutedEventArgs args)
...

我的预感是打印对话框在主 UI 线程中打开,并尝试访问由我自己的线程创建和拥有的文档,因此崩溃。

我有什么想法可以解决这个问题吗?我想将窗口保留在自己的线程中。

In my WPF app, I have particular Window which contains, amongst other controls, a DocumentViewer.

When this window is opened and loaded, it dynamically builds a FixedDocument with a progress indicator, and then displays it in the DocumentViewer. It works, and to improve the user experience, I run this window in its own thread, so that the main application window is still responsive while the document is being built.

Based on the tips at this web page, I open my window in a new thread like this:

public void ShowDocumentViewerWindow(params object[] data) {
    var thread = new Thread(() => {
        var window = new MyDocumentViewerWindow(new MyObject(data));
        window.Closed += (s, a) => window.Dispatcher.InvokeShutdown();
        window.Show();
        System.Windows.Threading.Dispatcher.Run();
    });
    thread.SetApartmentState(ApartmentState.STA);
    thread.Start();
}

I have been happy with this setup so far, but I just ran into an issue.

MyDocumentViewerWindow contains a print button, which references the built-in Print command, targeted at the DocumentViewer:

<Button Command="Print" CommandTarget="{Binding ElementName=MyDocumentViewer}">Print</Button>

Before I had the window in its own thread, this worked fine. But now, when I click it, the application crashes. Visual Studio 2010 highlights the following line from the above code as the crash location, with the message 'The calling thread cannot access this object because a different thread owns it.':

System.Windows.Threading.Dispatcher.Run();

The stack trace starts like this:

at System.Windows.Threading.Dispatcher.VerifyAccess()
at MS.Internal.Printing.Win32PrintDialog.ShowDialog()
at System.Windows.Controls.PrintDialog.ShowDialog()
at System.Printing.PrintQueue.GatherDataFromPrintDialog(PrintDialog printDialog, XpsDocumentWriter&amp; writer, PrintTicket&amp; partialTrustPrintTicket, PrintQueue&amp; partialTrustPrintQueue, Double&amp; width, Double&amp; height, String jobDescription)
at System.Printing.PrintQueue.CreateXpsDocumentWriter(String jobDescription, PrintDocumentImageableArea&amp; documentImageableArea)
at System.Windows.Controls.Primitives.DocumentViewerBase.OnPrintCommand()
at System.Windows.Controls.Primitives.DocumentViewerBase.ExecutedRoutedEventHandler(Object target, ExecutedRoutedEventArgs args)
...

My hunch is that the print dialog is opening in the main UI thread, and trying to access the document that is created and owned by my own thread, hence the crash.

Any ideas how I can solve this? I'd like to keep the window in its own thread.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

无戏配角 2024-12-10 04:08:27

经过更多谷歌搜索后,我偶然发现了以下线程,这似乎正是我遇到的问题。

PrintDialog 和辅助 UI 线程严重问题

在该线程中,这家伙最终使用了一个自定义的 PrintDialog 类(其源代码位于 此处),与内置 PrintDialog 非常相似,但进行了一些调整来修复这些跨线程错误(它还覆盖了 XPS Document Writer,它显然将自己进一步与应用程序的主 UI 线程联系在一起)

我复制并粘贴了该自定义 PrintDialog 的代码(并将该类重命名为ThreadSafePrintDialog),删除了我的“打印”按钮的 CommandTarget,而是使用我自己的“打印”方法:

private void Print_Executed(object sender, ExecutedRoutedEventArgs args) {
    var printDialog = new ThreadSafePrintDialog();
    if (!printDialog.ShowDialog(this)) return;

    printDialog.PrintDocument(DocumentViewer.Document.DocumentPaginator, "My Document");
}

工作完美。

After some more Googling, I stumbled across the following thread, which seems to be the exact issue I am having.

PrintDialog and a secondary UI thread severe problem

In that thread, the guy eventually uses a custom PrintDialog class (the source code of which is found here), which is much the same as built-in PrintDialog, but with a few tweaks to fix these cross-thread bugs (and it also overrides the XPS Document Writer, which apparently ties itself even further into the application's main UI thread)

I copied and pasted the code for that custom PrintDialog (and renamed the class to ThreadSafePrintDialog), removed my Print button's CommandTarget, and instead use my own Print method:

private void Print_Executed(object sender, ExecutedRoutedEventArgs args) {
    var printDialog = new ThreadSafePrintDialog();
    if (!printDialog.ShowDialog(this)) return;

    printDialog.PrintDocument(DocumentViewer.Document.DocumentPaginator, "My Document");
}

Works perfectly.

鹿童谣 2024-12-10 04:08:27

你的预感是正确的。当该对象已由另一个线程创建时,您无法在 UI 线程上访问该对象。

我相信您有几个选择:

  1. 您可以在 UI 线程上创建此文档,也许在后台线程中收集所需的信息,然后在 UI 线程上实际构造该对象。这取决于您的文档创建需要什么。你可以这样做:

    public void CreateDocument(T inputDataForDocumentCreation) {
      var uiDispatcher = Dispatcher.CurrentDispatcher;
      ThreadPool.QueueUserWorkItem(_ => {
        // 使用 yourDataForDocumentCreation 加载并创建文档组件
    
         调度程序.BeginInvoke(DispatcherPriority.Normal, () => {
         //实际创建文档(这将发生在UI线程上,因此可以从UI线程访问它)
      });
      });
    }
    
  2. 您也许可以将此命令发送到创建另一个文档的线程?保留该线程并执行 thread.Invoke(printMethod)

  3. 您可以查看 可冻结对象。查看本页底部的标题“创建您自己的 Freezable 类”。这将使您的文档线程安全,可以从与创建它的线程不同的线程进行访问。

Your hunch is correct. You cannot access this object on the UI thread when it has been created by another thread.

I believe you have a few options:

  1. You could create this document on the UI thread, perhaps gather the information that you need in a background thread and then actually construct the object on the UI thread. It depends what your document creation entails. You could do something like:

    public void CreateDocument(T inputDataForDocumentCreation) {
      var uiDispatcher = Dispatcher.CurrentDispatcher;
      ThreadPool.QueueUserWorkItem(_ => {
        // Load and create document components with yourDataForDocumentCreation
    
         dispatcher.BeginInvoke(DispatcherPriority.Normal, () => {
         //Actually create the document (this will happen on the UI thread, so it may be accessed from the UI thread)
      });
      });
    }
    
  2. You could perhaps send this command to the thread that creates this other document? Hold on to this thread and do a thread.Invoke(printMethod)

  3. You could look into Freezable Objects. Look at the bottom of this page, heading "Creating Your Own Freezable Class". This would make your document thread-safe to access from a different thread than that which created it.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文