Re: How to enable the close window button while showing a modal sheet?
On 9 Jan, 2013, at 6:11, Oleg Krupnov wrote: > I don't want to start a HIG flame on this, but just want to know if > it's technically possible to enable the close button of a window while > showing a modal sheet (NSApp beginSheet:modalForWindow:…) on it? The answer is in the documentation for that method: "While the application is in the run loop, it does not respond to any other events (including mouse, keyboard, or window-close events) unless they are associated with the sheet." Jim ___ 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
Cocoaheads Lake Forest meets tonight
CocoaHeads Lake Forest will be meeting on the second Wednesday of the month. We will be meeting at the Orange County Public Library (El Toro) community room, 24672 Raymond Way, Lake Forest, CA 92630 Please join us from 7pm to 9pm on Wednesday, December 12. Bring laptops, code, discussion topics, etc. As always, details can be found on the cocoaheads web site at www.cocoaheads.org ___ 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: simulating in a text field by pressing a button
I got it to work. The key is to explicitly load the Nib in the
constructor of my NSViewController subclass
- (id)init
{
[NSBundle loadNibNamed:kNibName owner:self];
self = [super initWithNibName:kNibName bundle:nil];
...
}
Checking the result of commitEditing when the user clicks my Add
button works fine. The caveat is that I have to check to see if my
target NSString's value is nil before I programmatically close my
modal sheet.
The target string can be nil if the user chose to discard changes in
the error panel that pops up on validation.
--
for hire: mac osx device driver ninja. kernel, usb and coreaudio drivers
-++---
http://wagerlabs.com | @wagerlabs | http://www.linkedin.com/in/joelreymont
-++---
___
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: simulating in a text field by pressing a button
What I'm trying to say is that the root of my Nib is a Window since I use it with NSPanel to display a modal sheet. The window does have a view which has a text field and a button. Do I need to have a subclass of NSWindowController just to load the Nib -and- a NSViewController to manage the text field and button and use commitEditing? Thanks, Joel -- for hire: mac osx device driver ninja. kernel, usb and coreaudio drivers -++--- http://wagerlabs.com | @wagerlabs | http://www.linkedin.com/in/joelreymont -++--- ___ 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: simulating in a text field by pressing a button
NSWindowController does not implement commitEditing, though.
NSViewController does but I have to use NSWindowController since my
dialog is a modal window (sheet).
Can I have my cake and eat it too?
On Mon, Jan 7, 2013 at 9:40 PM, jonat...@mugginsoft.com
wrote:
>
> On 2 Jan 2013, at 21:03, Joel Reymont wrote:
>
>> I have a dialog (sheet) with a single text field and a button.
>>
>> I'm using Cocoa Bindings to validate the value in the text field and
>> set a string field in the File's Owner.
>>
>> This works fine but I would like to trigger the same sequence of
>> events when pressing the button. How do I do this?
>
> Try calling -commitEditing on your object controller.
>
> I also on occasion make use of the following NSWindow category method.
> Most controls perform validation etc when they loose first responder status.
> This method causes validation to occur by temporarily making the window its
> own responder.
>
> /*
>
> end all editing in window
>
> */
> - (BOOL)endEditing:(BOOL)force
> {
> id firstResponder = [self firstResponder];
>
> // gracefully end all editing in a window named aWindow
> if ([self makeFirstResponder:self]) {
> // All editing is now ended and delegate messages sent etc.
> } else if (force) {
> // For some reason the text object being edited will not
> resign
> // first responder status so force an end to editing anyway.
> // This is probably a bad idea as the first responder is probably
> refusing to resign
> // its status because of a pending or failed validation.
> // forcing the edit can leave our model in an invalid state.
> [self endEditingFor:nil];
> } else {
> return NO;
> }
>
> // restore the first responder once editing completed.
> // this is required in situations where this message is sent from
> // - (void)windowDidResignKey:(NSNotification *)notification.
> // a panel, such as the find panel, may be being displayed.
> // it will require the window's firstResponder to be maintained.
> [self makeFirstResponder:firstResponder];
>
> return YES;
> }
>
>
> Regards
>
> Jonathan Mitchell
> Mugginsoft LLP
>
>
> ___
>
> 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/joelr1%40gmail.com
>
> This email sent to joe...@gmail.com
--
--
for hire: mac osx device driver ninja. kernel, usb and coreaudio drivers
-++---
http://wagerlabs.com | @wagerlabs | http://www.linkedin.com/in/joelreymont
-++---
___
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: making the most of a symbolic breakpoint
On Wed, Jan 9, 2013, at 12:22 PM, Greg Parker wrote: > > Look for the iOS ABI Function Call Guide. > > http://developer.apple.com/library/ios/#documentation/Xcode/Conceptual/iPhoneOSABIReference/Articles/ARMv6FunctionCallingConventions.html > http://developer.apple.com/library/ios/#documentation/Xcode/Conceptual/iPhoneOSABIReference/Articles/ARMv7FunctionCallingConventions.html Ah, thank you! I don't know why I was so incapable of finding these documents on my own. On Wed, Jan 9, 2013, at 12:33 PM, Greg Parker wrote: > > Without heroic measures, a true ABI break means either "your old apps > don't work" or "there are two copies of the OS shared library stack in > memory". The sub-optimal parts of our ARM ABI aren't bad enough to > justify that cost. Why should iOS devs miss out on the magic of Universal Procedure Pointers? :) --Kyle Sluder ___ 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: making the most of a symbolic breakpoint
On Jan 9, 2013, at 12:01 PM, Kyle Sluder wrote: > On Wed, Jan 9, 2013, at 11:04 AM, John McCall wrote: >> There is no one standard calling convention on ARM; ARM has revised its >> suggested ABI multiple times. iOS follows a relatively old convention >> which, among other things, does not pass floating-point arguments in >> floating-point registers. This is suboptimal but not fixable without a >> total ABI break. > > That's what I was afraid of. :( Did Apple take advantage of the move to > ARMv7 to introduce a more performant calling convention? No. On iOS, ARMv7 and ARMv6 code can interoperate freely, so there was no opportunity to introduce changes to parameter-passing. Without heroic measures, a true ABI break means either "your old apps don't work" or "there are two copies of the OS shared library stack in memory". The sub-optimal parts of our ARM ABI aren't bad enough to justify that cost. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: making the most of a symbolic breakpoint
On Jan 9, 2013, at 9:29 AM, Kyle Sluder wrote: > The standard ARM calling convention can be found here: > http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042e/IHI0042E_aapcs.pdf#page15 > > Sadly I can't find anything on the iOS Dev Center that assures me that iOS > obeys the standard calling convention. This concern is real; for example, > Windows does not obey the AMD64 calling convention on x86-64. Look for the iOS ABI Function Call Guide. http://developer.apple.com/library/ios/#documentation/Xcode/Conceptual/iPhoneOSABIReference/Articles/ARMv6FunctionCallingConventions.html http://developer.apple.com/library/ios/#documentation/Xcode/Conceptual/iPhoneOSABIReference/Articles/ARMv7FunctionCallingConventions.html tl;dr: iOS follows one of ARM's AAPCS versions, with a handful of exceptions that are documented in the links above. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: making the most of a symbolic breakpoint
On Wed, Jan 9, 2013, at 11:04 AM, John McCall wrote: > There is no one standard calling convention on ARM; ARM has revised its > suggested ABI multiple times. iOS follows a relatively old convention > which, among other things, does not pass floating-point arguments in > floating-point registers. This is suboptimal but not fixable without a > total ABI break. That's what I was afraid of. :( Did Apple take advantage of the move to ARMv7 to introduce a more performant calling convention? Moreover, this seems like information that should be documented as well for iOS as it is for the desktop. --Kyle Sluder ___ 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: making the most of a symbolic breakpoint
On Jan 9, 2013, at 9:29 AM, Kyle Sluder wrote: > On Jan 9, 2013, at 9:17 AM, Joel Reymont wrote: >> Tech Note 2239 refers to 64-bit register details in Listing 10, >> Objective-C runtime 'secrets'. These details can be found here >> >> http://developer.apple.com/library/mac/#technotes/tn2124/_index.html >> >> It should be straightforward to translate to ARM and LLDB now. > > One cannot blithely translate calling conventions into the terms of another > architecture and expect things to always work. > > The previous link you provided covers the simple case of four register-sized > arguments. It doesn't cover a bunch of other important cases: > > - Function calls with more than 4 arguments > - Floating-point arguments > - Aggregate (struct) or larger-than-register-size arguments > - Functions with variable arguments > - Functions that return floats or structs or other non-register-sized types > > OS X follows the AMD64 Unix ABI, which defines the calling convention for > these kinds of function calls in ways that don't necessarily map to ARM > processors in use on iOS devices. > > The standard ARM calling convention can be found here: > http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042e/IHI0042E_aapcs.pdf#page15 > > Sadly I can't find anything on the iOS Dev Center that assures me that iOS > obeys the standard calling convention. This concern is real; for example, > Windows does not obey the AMD64 calling convention on x86-64. There is no one standard calling convention on ARM; ARM has revised its suggested ABI multiple times. iOS follows a relatively old convention which, among other things, does not pass floating-point arguments in floating-point registers. This is suboptimal but not fixable without a total ABI break. At entry to the function, r0 will be 'self' unless the method returns its result indirectly, in which case r0 will be the result pointer and r1 will be 'self'. This difference is why objc_msgSend (and objc_msgSendSuper) has an _stret variant that's used for such methods. (The alternative, changing the calling convention for methods so that 'self' was always in the same register, would make it more difficult to use a normal function pointer as an ObjC IMPL.) This is only true at the point of entry to the method; the prologue may need to do work that "corrupts" these registers. For example, this may be true if the method requires exception-handling. John. ___ 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: making the most of a symbolic breakpoint
On Jan 9, 2013, at 9:17 AM, Joel Reymont wrote: > Tech Note 2239 refers to 64-bit register details in Listing 10, > Objective-C runtime 'secrets'. These details can be found here > > http://developer.apple.com/library/mac/#technotes/tn2124/_index.html > > It should be straightforward to translate to ARM and LLDB now. One cannot blithely translate calling conventions into the terms of another architecture and expect things to always work. The previous link you provided covers the simple case of four register-sized arguments. It doesn't cover a bunch of other important cases: - Function calls with more than 4 arguments - Floating-point arguments - Aggregate (struct) or larger-than-register-size arguments - Functions with variable arguments - Functions that return floats or structs or other non-register-sized types OS X follows the AMD64 Unix ABI, which defines the calling convention for these kinds of function calls in ways that don't necessarily map to ARM processors in use on iOS devices. The standard ARM calling convention can be found here: http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042e/IHI0042E_aapcs.pdf#page15 Sadly I can't find anything on the iOS Dev Center that assures me that iOS obeys the standard calling convention. This concern is real; for example, Windows does not obey the AMD64 calling convention on x86-64. --Kyle Sluder ___ 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: making the most of a symbolic breakpoint
Tech Note 2239 refers to 64-bit register details in Listing 10, Objective-C runtime 'secrets'. These details can be found here http://developer.apple.com/library/mac/#technotes/tn2124/_index.html It should be straightforward to translate to ARM and LLDB now. -- for hire: mac osx device driver ninja. kernel, usb and coreaudio drivers -++--- http://wagerlabs.com | @wagerlabs | http://www.linkedin.com/in/joelreymont -++--- ___ 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: making the most of a symbolic breakpoint
Ah, mea culpa! This then. http://developer.apple.com/library/ios/#technotes/tn2239/_index.html See the listings under Objective-C and the differences under Some Assembly required. -- for hire: mac osx device driver ninja. kernel, usb and coreaudio drivers -++--- http://wagerlabs.com | @wagerlabs | http://www.linkedin.com/in/joelreymont -++--- ___ 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: making the most of a symbolic breakpoint
On Jan 9, 2013, at 6:56 AM, Joel Reymont wrote: > Off the top of my head: > > po `$rdi` This is correct on x86-64, but OP is on iOS. --Kyle Sluder ___ 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: Cococa-Dev : was [coredata count not fulfill fault after object delete]
On 8 Jan 2013, at 05:53, Martin Hewitson wrote:
>
> On Jan 7, 2013, at 08:44 PM, Mike Abdullah wrote:
>
>>
>> On 7 Jan 2013, at 16:35, Martin Hewitson wrote:
>>
>>> Hi Francisco,
>>>
>>> Thanks for the feedback!
>>>
>>> What you suggest sounds like it might fix the problem, but I'm wondering
>>> how best to do this. Currently I'm just calling -remove: on the tree
>>> controller to delete the selected object(s). Of course, if I clear the
>>> selection first, then -remove: doesn't do anything. I can grab an array of
>>> the selected objects before clearing the selection then use
>>> NSManagedObjectContext's -deleteObject:. So something like this:
>>>
>>> // get a pointer to the selected items
>>> NSArray *items = [self selectedObjects];
>>>
>>> // clear selection
>>> [self setSelectionIndexPaths:@[]];
>>>
>>> // now delete from the MOC
>>> for (NSManagedObject *item in items) {
>>>[self.managedObjectContext deleteObject:item];
>>>[self.managedObjectContext processPendingChanges];
>>> }
>>>
>>> Does that look sensible to you?
>>
>> Why are you calling -processPendingChanges at each iteration of the loop?
>> Calling it yourself is rarely needed, and best done only with justification.
>>
>
> I read in that thread that I referenced (I think) that it may be necessary to
> do this to avoid/handle objects being deleted twice (if a parent and child
> are selected, then deleted). To be honest, I'm just trying things to see what
> works. Since this problem only occurs on 10.6.8, I think I'm looking for a
> work-around.
Hmm. In my case I go to some lengths to figure out which objects don't need to
be deleted, because an ancestor has already been deleted. It does seem simpler
your way.
I wonder though — I don't believe there is any harm in asking Core Data to
delete an object that's already been marked for deletion. And indeed, you code
is doing that. The difference the -processPendingChanges call makes is that
handling the delete rule will happen during that call, so child objects are
already marked for deletion.
___
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: making the most of a symbolic breakpoint
Off the top of my head: po `$rdi` Works on exceptions, haven't tried with symbolic breakpoints. Above assumes you are using lldb. On Wed, Jan 9, 2013 at 2:08 PM, Matt Neuburg wrote: > When I've set a symbolic breakpoint for an Objective-C method and we pause at > that breakpoint in assembler, how can I find out things like what object this > message was sent to and what argument values were passed? (This is in iOS if > that makes a difference.) Thx - m. -- for hire: mac osx device driver ninja. kernel, usb and coreaudio drivers -++--- http://wagerlabs.com | @wagerlabs | http://www.linkedin.com/in/joelreymont -++--- ___ 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: making the most of a symbolic breakpoint
On Jan 9, 2013, at 8:08 AM, Matt Neuburg wrote: > When I've set a symbolic breakpoint for an Objective-C method and we pause at > that breakpoint in assembler, how can I find out things like what object this > message was sent to and what argument values were passed? (This is in iOS if > that makes a difference.) Thx - m. > > -- > matt neuburg, phd = m...@tidbits.com, http://www.apeth.net/matt/ > pantes anthropoi tou eidenai oregontai phusei > Programming iOS 5! http://shop.oreilly.com/product/0636920023562.do > RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html > TidBITS, Mac news and reviews since 1990, http://www.tidbits.com > > > ___ > > 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/zav%40mac.com > > This email sent to z...@mac.com ___ 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
making the most of a symbolic breakpoint
When I've set a symbolic breakpoint for an Objective-C method and we pause at that breakpoint in assembler, how can I find out things like what object this message was sent to and what argument values were passed? (This is in iOS if that makes a difference.) Thx - m. -- matt neuburg, phd = m...@tidbits.com, http://www.apeth.net/matt/ pantes anthropoi tou eidenai oregontai phusei Programming iOS 5! http://shop.oreilly.com/product/0636920023562.do RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html TidBITS, Mac news and reviews since 1990, http://www.tidbits.com ___ 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: PDFView drawPage called often after selecting text
On Jan 9, 2013, at 09:25 AM, Kyle Sluder wrote: > On Jan 8, 2013, at 11:43 PM, Martin Hewitson > wrote: > >> Some interesting points/problems >> >> - if I use -drawPage: instead, then the focus ring has the wrong size and >> overlaps the displayed pages. Don't know why. >> - doing this in -drawPage: or -drawPagePost: solves the issue I was having >> - using [self bounds] rather than [[self documentView] bounds] produces no >> visible focus ring > > The documentation strongly implies that -drawPage: is called with a graphics > context that's been set up for drawing in the page's coordinate space, > whereas -drawPagePost: is documented to do its drawing in the PDFView's > coordinate space. Thanks, Kyle. That explains what I see. Somehow I failed to extract those juicy facts from the documentation. Martin > > --Kyle Sluder ___ 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: PDFView drawPage called often after selecting text
On Jan 8, 2013, at 11:43 PM, Martin Hewitson wrote: > Some interesting points/problems > > - if I use -drawPage: instead, then the focus ring has the wrong size and > overlaps the displayed pages. Don't know why. > - doing this in -drawPage: or -drawPagePost: solves the issue I was having > - using [self bounds] rather than [[self documentView] bounds] produces no > visible focus ring The documentation strongly implies that -drawPage: is called with a graphics context that's been set up for drawing in the page's coordinate space, whereas -drawPagePost: is documented to do its drawing in the PDFView's coordinate space. --Kyle Sluder ___ 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
