Definitely follow that train. Doing things with the wrong context is definitely one possibility. By the way, the setNeedsDisplay doesn’t need to happen on that view; it could be a subview, and there could be some other operation that implicitly causes such a dirtying—remember, there’s also setNeedsDisplayInRect:. The app I referred to was doing stuff with the current field editor, recalculating its size and position to provide a combo box-like display, as a side effect of a side effect of the draw. There’s some graphics context debugging options you can turn on, as well as coloration options that might also help. You mentioned you broke on setNeedsDisplay. Try adding setNeedsDisplayInRect: and turn on a breakpoint for all classes, not just that one view. -- Gary L. Wade http://www.garywade.com/ <http://www.garywade.com/> > On Nov 21, 2016, at 1:13 PM, Jeff Evans <jev...@ars-nova.com> wrote: > > 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
