Issue with contents of PDFView not being refreshed after associating PDFDocument

MichaelBothMichaelBoth AUMember ✭✭✭
edited September 2017 in Xamarin.Mac

I'm having an odd issue with a Xamarin Mac application that has been running fine in the field for a couple of years. As part of the application I generate HTML + some JS, then convert this to a PDF, and load the PDF into a PDFView for display to the user. The code is very similar to this:

string sSourcePathForPDFFile = System.IO.Path.Combine(SourcePathForResources, "GeneratedPDF.pdf");
var pdf URL = EscapedFullPathURL("file://" + sSourcePathForPDFFile);
ThePDFView.Document = PDFDocument;

On my business partner's Mac (which is running 10.12.6) this code does NOT result in the PDF being shown in the PDFView; the PDFView remains blank. However, on my development machine (also running 10.12.6) it works fine. Our application also works fine on another test Mac (running 10.11.6). Interestingly, if I move this code into "AwakeFromNib" (using a pre-generated PDF file), the PDF works fine on the problematic Mac; it's only if the PDFView is set to load a new document when necessary as the user is viewing the form that it doesn't work.

Other info - I'm using Visual Studio for Mac v7.1 build 1297, Xamarin.Mac v3.6.0.19, and Mono I've got a simple test application that demonstrates the issue.

I thought that perhaps I need to cajole the PDFView into refreshing, so I have also tried adding these various lines:

ThePDFView.NeedsDisplay = true;
ThePDFView.NeedsLayout = true;

... after the 'Document' assignment, but this makes no difference on the problematic Mac.

Has anyone else come across this kind of behaviour? From research it seems Apple kind of mucked up PDFKit in different ways recently, however as it stands this is a show-stopper issue for us, and I can't assume it's only going to be a problem on my partner's computer.



  • ChrisHamonsChrisHamons USXamarin Team Xamurai
    edited September 2017

    That is rather strange, but it feels like it's a PDFKit bug.

    We are often a very thin layer above obj-c, and I can't imagine this being in XM code.

    A few random "I have no clue but maybe try this" ideas:

    • Make sure all of the code dealing with PDF are on the UI thread.
    • Maybe try shoving the ThePDFView.Document = PDFDocument; code in a BeginInvokeOnMain thread to see if there is some strange threading issue?
    • NeedsDisplay should be sufficient to force a draw. Maybe try writing the pdf in question to disk somewhere, and seeing if it is generated correctly on the "bad" machine. It could help separate "the pdf is being made wrong" vs "it's being shown wrong"
    • Maybe try round tripping it to disk, to see if the behavior changes

    Worse case scenario you could write a thin slice in obj-c to see if you can reproduce the strange behavior in obj-c (to file a radar w\ Apple).

  • MichaelBothMichaelBoth AUMember ✭✭✭

    Thanks for the reply, Chris. On my minimal test app the replicates the issue I have a 'known-good' PDF bundled in, and the view does refresh properly if the .Document assignment is made in "AwakeFromNib"; it's just on this one machine out of three where it doesn't refresh in response to a button-click (which then I assume eliminates issues due to not running on the UI thread). But I will try a 'BeginInvoiceOnMain' wrapper and see if that makes a difference.

    After that, yep, it's deeper into obj-c territory, which would be terrible use as this and the other issue I posted about and to which you responded, many thanks!, are release-blockers for us.

    I'll post back with what I discover in case it helps other people.

Sign In or Register to comment.