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

NSComboBoxCell subclass pointers?

[Robert Monaghan]

Hi Everyone!

This one has me stumped..

I have been working on a custom UI for my Cocoa application. By looking around 
the internet, I have managed to learn how to subclass a large number of UI 
objects on MacOSX. In many cases I could make the appearance work the way I 
want.

The last UI element that I am working on, is NSComboBoxCell. It appears to be a 
NSTextFieldCell with an NSButtonCell attached. It seems fairly easy to override
“drawWithFrame:inView"  and draw a replacement artwork. But there are a bunch 
of unknowns/pitfalls..

The part that I suspect that I have to subclass is the NSButtonCell that I 
believe is drawing the "Arrow Button”.
But how is this done, along side the NSTextField that makes up the 
NSComboBoxCell class? When I look at the NSComboBoxCell header files, I don’t 
see any obvious clues to figure out the geometry of the NSButtonCell, that is 
apparently being used alongside the NSTextField, itself.

Are there any ways to get to the NSButtonCell stored inside the NSComboBoxCell 
Object? (Ideally so that I can override and install my own NSButtonCell..)

Thanks in advance!

bob..



___

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