Re: Flipped print previews

[Jeff Evans]

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  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

Re: Flipped print previews

[Gary L. Wade]

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/ 
> On Nov 21, 2016, at 1:13 PM, Jeff Evans  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  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 

Re: Flipped print previews

[Gary L. Wade]

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  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
> 


___

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

Flipped print previews

[Jeff Evans]

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











___

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

Flipped print previews

[Jeff Evans]

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











___

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