Getting ObjectDisposedException after changing DocumentSource

6 posts, 0 answers
  1. Dean K.
    Dean K. avatar
    55 posts
    Member since:
    Aug 2011

    Posted 22 Jul 2013 Link to this post

    I have a simple RadPdfViewer declared in my UserControl:

        <t:RadPdfViewer Grid.Row="1" x:Name="PdfViewer" DocumentSource="{Binding Uri}" 
                        PreviewKeyDown="PdfViewer_OnPreviewKeyDown"
                        DocumentChanged="PdfViewer_OnDocumentChanged"/>

    Randomly (although it appears that this exception does not occur if I wait for the current document to be fully rendered and the progress indicator to be removed by the RadPdfViewer) when "Uri" property in my VM (which is a simple string property) is changed to new Uri of some pdf file I get ObjectDisposedException with "Cannot access a closed file." message.

    StackTrace:

       at System.IO.__Error.FileNotOpen()
       at System.IO.FileStream.get_Position()
       at Telerik.Windows.Documents.Fixed.FormatProviders.Pdf.PdfReader.Readers.PdfReaderBase.ReadInternal() in c:\TB\117\WPF_Scrum\Release_WPF\Sources\Development\Documents\Fixed\Core\FormatProviders\Pdf\PdfReader\Readers\PdfReaderBase.cs:line 174

    Exception Detail:
    System.ObjectDisposedException occurred
      HResult=-2146232798
      Message=Cannot access a closed file.
      Source=mscorlib
      ObjectName=""
      StackTrace:
           at System.IO.__Error.FileNotOpen()
           at System.IO.FileStream.get_Position()
           at Telerik.Windows.Documents.Fixed.FormatProviders.Pdf.PdfReader.Readers.PdfReaderBase.get_Position() in c:\TB\117\WPF_Scrum\Release_WPF\Sources\Development\Documents\Fixed\Core\FormatProviders\Pdf\PdfReader\Readers\PdfReaderBase.cs:line 55
      InnerException:

    Could you please take a look?
  2. Alexander
    Admin
    Alexander avatar
    41 posts

    Posted 25 Jul 2013 Link to this post

    Hi Dean,

    RadPdfViewer loads the documents asynchronously. When you change the DocumentSource before the document has loaded, the stream of the document is being closed but the loading continues and RadPdfViewer tries to access a closed stream. This is why an exception is being thrown. 

    I hope this is helpful. Please, do not hesitate to contact us if you have any other questions.

    Regards,
    Alexander
    Telerik
    TRY TELERIK'S NEWEST PRODUCT - EQATEC APPLICATION ANALYTICS for WPF.
    Learn what features your users use (or don't use) in your application. Know your audience. Target it better. Develop wisely.
    Sign up for Free application insights >>
  3. UI for WPF is Visual Studio 2017 Ready
  4. Dean K.
    Dean K. avatar
    55 posts
    Member since:
    Aug 2011

    Posted 25 Jul 2013 Link to this post

    Thanks but what's the solution? I tried placing the try/catch block when setting the DocumentSource but the catch block code is never reached...

    I tried catching the exception in DocumentChanged event as well but this exception is thrown before this event fires and I don't see any other RadPdfViewer event that looks like a good candidate for catching this exception...

    Where exactly can I catch this exception?

    I mean, you explained why the exception is thrown and that's all fine and dandy but not a word on how to handle it?

    I'm just going through all the methods and events of RadPdfViewer and I just don't see a 'DocumentLoaded' property or event that would help me avoid this exception being thrown when DocumentSource is changed before the previous file finished loading...

    There is 'DocumentSource.Loaded' event but this event cannot be subscribed to when RadPdfViewer is loaded because at that point DocumentSource is obviously null so where do you subscribe to it...
  5. Kammen
    Admin
    Kammen avatar
    312 posts

    Posted 29 Jul 2013 Link to this post

    Hi Dean,

    Actually, this exception is handled by the DocumentSource, so the only reason you could see it is because you have enabled "Break when an exception is thrown" option. This exception should not affect your application's behavior at all.

    Note that using exceptions is a common approach when you want to stop/cancel asynchronous operations so I cannot see any problem using it in this case as it is properly handled in the DocumentSource class.

    Hope this answers your questions.

    Regards,
    Kammen
    Telerik
    TRY TELERIK'S NEWEST PRODUCT - EQATEC APPLICATION ANALYTICS for WPF.
    Learn what features your users use (or don't use) in your application. Know your audience. Target it better. Develop wisely.
    Sign up for Free application insights >>
  6. Dean K.
    Dean K. avatar
    55 posts
    Member since:
    Aug 2011

    Posted 29 Jul 2013 Link to this post

    Wow, you make it sound as if having the "Break when an exception is thrown" option enabled is something weird... isn't it exactly what every developer wants when debugging?

    BTW, where exactly can I find this "little", unimportant, detail in your RadPdfViewer documentation?

    Thanks,

    Dean
  7. Iva Toteva
    Admin
    Iva Toteva avatar
    1319 posts

    Posted 31 Jul 2013 Link to this post

    Hi Dean,

    Enabling the "Break  when an exception is thrown" option can indeed be useful in some cases. However, with this option the debugger will break even on handled exceptions such as the ObjectDisposedException (compared to the option "Break when an exception is user-unhandled"). Following up on one of your previous comments, trying to surround the code that is triggering the exception in a try/catch block will also not change the behavior of the application with this more defensive option.

    Having in mind that you also agree that using exceptions internally is acceptable as long as they do not propagate to the users of the control as unhandled exceptions, what you can do is to uncheck the option for breaking on every occurrence of this specific exception.

    When it comes to documenting this specifics of RadPdfViewer, we believe this is not required because it describes the particular implementation of the feature and not its use. Furthermore, it may cause greater confusion because developers will try to handle the exception themselves, which as pointed out is not required.

    I hope you find this point of view valid.

    Regards,
    Iva Toteva
    Telerik
    TRY TELERIK'S NEWEST PRODUCT - EQATEC APPLICATION ANALYTICS for WPF.
    Learn what features your users use (or don't use) in your application. Know your audience. Target it better. Develop wisely.
    Sign up for Free application insights >>
Back to Top
UI for WPF is Visual Studio 2017 Ready