Re: App rejection due to app-sandboxing invalid entitlement
On Oct 26, 2012, at 10:35 PM, Martin Hewitson martin.hewit...@aei.mpg.de wrote: So, the story's not over. I resubmitted and the app was reviewed quickly, but rejected again with the same rejection note. So, what now? Not sure how to figure out my error, other than to pay for DTS... Out of curiosity, when you resubmitted, did you also provide a detailed description for why you were using the entitlements you requested? I suspect they're using an automated system that tells them to reject. That would prompt them to look at the description the developer provided to see if they made a case for what they're doing. Cheers, Curt - Curt Clifton, PhD Software Engineer The Omni Group www.curtclifton.net ___ 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: Timeout after application:openFile: stalling applescript
On Sep 19, 2012, at 12:17 PM, Kyle Sluder k...@ksluder.com wrote: I think AppleScript might be a red herring here. We're seeing a similar slowdown in use of NSOpenPanel in our apps. We filed a radar on this problem this afternoon, rdar://12342164. It's in open radar as well. Here's the key bit of the description: AppKit uses the private class NSLocalWindowWrappingRemoteWindow to shove the open sheet into our window but redirect to Power Box for the internals. When the user clicks cancel or open in the open sheet, the sheet loses key, and AppKit revalidates all the toolbar items. The NSLocalWindowWrappingRemoteWindow instance is still in the responder chain at this point. We're using a custom target-selection mechanism, called OATargetSelection. OATargetSelection is triggered by an override of -[NSApplication targetForAction:to:from:]. That mechanism traverses the responder chain from the first responder of the key window and the main window. It also checks things like delegates, window controllers, and---crucially---supplementalTargetForAction. OATargetSelection calls supplementalTargetForAction on the NSLocalWindowWrappingRemoteWindow instance. NSLocalWindowWrappingRemoteWindow's supplementalTargetForAction dispatches to the Power Box instance, which doesn't respond. It's busy going away. The IPC call times out in 300 ms, supplementalTargetForAction returns nil, and we merrily chase the rest of the responder chain. Debugging shows that the time out occurs in _dispatch_semaphore_wait_slow, which is tail-called by dispatch_semaphore_wait. The time-out argument to dispatch_semaphore_wait is generated by a call to dispatch_time with a time-out offset of 300,000,000 nanoseconds. That matches the 300 ms delay we observe. Further the return code of _dispatch_semaphore_wait_slow is 49, indicating a time-out. This time-out delay happens for every validation. After the four seconds that this consumes, the sheet finally leaves the responder chain, our completion handler for the open sheet is called, and the UI becomes responsive again. Unfortunately we haven't found a workaround. All notifications and override points that we've tried are invoked after the time outs occur. Cheers, Curt - Curt Clifton, PhD Software Engineer The Omni Group www.curtclifton.net ___ 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: Debugging -setNeedsDisplayInRect:
On Jul 27, 2012, at 8:55 AM, Nick Zitzmann n...@chronosnet.com wrote: But I need to be able to see **all** invocations of the method from **all** NSViews to catch the culprit, because I have a rather complicated view hierarchy, including some views for which I don't have the source, and I don't know exactly which view is doing this. In order to do that, I need to set a conditional breakpoint, and this would be easy if an NSRect could be stored in a register, but how do I set a conditional breakpoint when the variable I want to investigate is on the stack? And where would I find each of the CGFloats on the stack? For debugging, you might consider swizzling NSView's -setNeedsDisplayInRect: to do the conditional logging that Markus suggested. Cheers, Curt - Curt Clifton, PhD Software Engineer The Omni Group www.curtclifton.net ___ 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: Accessibility issues with NSPopover
On May 10, 2012, at 2:06 AM, Motti Shneor wrote: does anybody know how to regain focus on an NSPopover after it lost user focus? (after another window becomes key and main) I could not do it. The only way I found was to close/delete the NSPopover and recreate it. Seems bad solution to me. Just a guess here, but what happens if you call -[NSWindow makeFirstResponder:] on the window containing the view to which the popover is attached, passing one of the NSResponders from your popover as the argument? Although NSPopover has its own hidden window, it seems to hide some fairly intimate connections to its host window. Cheers, Curt - Curt Clifton, PhD Software Engineer The Omni Group www.curtclifton.net ___ 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: viewWillAppear not called with UINavigationController containment
On Dec 27, 2011, at 5:51 AM, Roland King wrote: // tell each of the controllers we're adding that they are being added and prepare the ones being removed for removal for( UIViewController *controller in appearingControllers ) [ self addChildViewController:controller ]; [ disappearingControllers makeObjectsPerformSelector:@selector( willMoveToParentViewController: ) withObject:nil ]; [ appearingControllers makeObjectsPerformSelector:@selector( didMoveToParentViewController: ) withObject:self ]; [ disappearingControllers makeObjectsPerformSelector:@selector( removeFromParentViewController ) ]; // get the views in order NSArray *newViews = [ viewControllers valueForKey:@view ]; // views then added to our view That looks about like what we're doing successfully. The only difference I see is that we're adding/removing views between the paired view controller calls. In the example below, both self and slice are UIViewController subclasses. // removing [slice willMoveToParentViewController:nil]; if ([slice isViewLoaded] slice.view.superview == view) [slice.view removeFromSuperview]; [slice removeFromParentViewController]; ... // adding [self addChildViewController:slice]; [view addSubview:slice.view]; [slice didMoveToParentViewController:self]; HTH. Cheers, Curt ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
