Thanks again Gary - but I looked into this by breaking at attempts to call setDisplayNeeded on the view, with no luck. Can't find anything in my code that is dirtying the view during the print draw.
However, another idea arises: I am using this method to obtain the current CGContext during all this drawing of various objects: NSGraphicsContext* nsContext = [NSGraphicsContext currentContext]; CGContextRef currentCGContext = [nsContext CGContext]; I notice that during [printOperation runOperation] the nsContext returned is an NSPrintPreviewGraphicsContext*, which sounds right. But if, as is usually the case, the print preview draws reduced and mirrored, I force a redraw of the print preview by touching one of the dialog controls - and then I get a different NSPrintPreviewGraphicsContext*, and this one always works properly. I should think that the graphics context would be the same for the initial draw and a subsequent refresh, so perhaps this is a hint. The two certainly behave differently. But why would the initial one be wrong? Another hint is that sometimes the first attempt to print a file works shows a correct preview, while subsequent ones require the refresh to display properly. More often the initial attempt is wrong. Don't you hate those problems that are not reliably repeatable? Yet that also should be a hint, if I could make sense of it. Jeff On Nov 20, 2016, at 11:43 PM, Gary L. Wade wrote: I remembered seeing something like that in an app that had been doing some things deep with the drawRect: call that was causing the view to become dirty again. I fixed it by getting rid of that code. Try looking for something like that first. -- Gary L. Wade (Sent from my iPhone) http://www.garywade.com/ > On Nov 20, 2016, at 9:33 PM, Jeff Evans <jev...@ars-nova.com> wrote: > > p.s. As I was unclear: the image returns YES to flipped and draws on that > assumption, looking good. When I say the image in the print dialog is > "flipped" I mean that it is backwards - mirrored - the reverse of what it > should be - as if it were an unflipped view - until it is drawn a second time. > ---- > > I'm printing from a view-based OSX app (compiled for 10.11), and have found > it easy to print by creating a print operation from the view in question. The > view is flipped (that is, returns YES to IsFlipped) and looks good on screen. > The view creates a print operation this way: > > NSPrintOperation* printOp = [NSPrintOperationWithView: self printInfo: > [NSPrintInfo sharedPrintInfo]]; > > //..then setting of margins, etc. in [printOp printInfo], then > > [printOp runOperation] > > Running the operation does the whole thing and creates a beautiful preview > of the page - > > BUT not on the first draw. The initial image displayed in the print dialog > is flipped and often reduced to miniature. If you touch the pages-to-print > choice, or the All choice, the preview image in the print dialog redraws and > redraws correctly. The actual print then works fine. > > This does make it more difficult print to pdf when the first draw is wrong, > since the pdf is also wrong on the first draw. But if I choose "view pdf in > preview" then all is well - it draws nicely and I can then use Preview's > export command to save it, or print. > > But this is no way to live. Don't want to have to tell customers to use a > work-around. > > There must be something that needs initializing that is corrected after > that first draw. Or is this just a glitch? > > > Thanks, Jeff > -- If this email is spam, please report it to https://support.onlymyemail.com/view/report_spam/MTAxOTYyOjE5NDI1ODMyNTY6amV2YW5zQGFycy1ub3ZhLmNvbTpkZWxpdmVyZWQ _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
