Re: Safe time to add accessory view to NSSavePanel in sandboxed app?
That looks familiar back when I dealt with adding an accessory view under sand boxing. I don't have the code base available to me to know what I did differently or remind me further, but I know I did something different in the sandboxed version than the non-sandboxed. There's a number of web pages you should find related to the save panel UI hierarchy under sand boxing that should help, though. Search on things like NSSavePanel, sandbox, NSRemoteView, etc. -- Gary L. Wade (Sent from my iPhone) http://www.garywade.com/ > On Oct 19, 2015, at 8:22 AM, Marek Hrušovský wrote: > > I just went through my crashes and this thread popped up in google. > > I have additional information (one helpful method in the stack). Even if I > dig deep I still can't figure out what can cause the issue. Is anyone able > to get from "_hierarchyDidChangeInView" the line where it crashes? > > > Anyway I created rdar://23165196 > > > Marek. > > > Date/Time: 2015-10-14T19:16:34Z > > OS Version: Mac OS X 10.11.0 (15A278b) > > Report Version: 104 > > > Exception Type: SIGSEGV > > Exception Codes: SEGV_MAPERR at 0x7fc7a764438 > > Crashed Thread: 0 > > > Thread 0 Crashed: > > 0 libobjc.A.dylib 0x7fff84dcbe5d objc_msgSend + > 29 > > 1 ViewBridge 0x7fff9519ea42 > -[NSVBAccessoryWindow _hierarchyDidChangeInView:] + 69 > > 2 AppKit 0x7fff86593aea -[NSView > _setSuperview:] + 2602 > > 3 AppKit 0x7fff86592c28 -[NSView > addSubview:] + 448 > > 4 AppKit 0x7fff865fa754 -[NSWindow > setContentView:] + 638 > > 5 ViewBridge 0x7fff951d1253 > setWindowContentView + 75 > > 6 ViewBridge 0x7fff951b5d8b > -[NSRemoteViewBase setAccessoryView:] + 208 > > 7 AppKit 0x7fff86df9ed8 > -[NSVBSavePanel(NSSavePanelSPI) _sendAccessoryView:] + 49 > > 80x00010b56e3b0 0x10b4bf000 + 717744 > >> On Sat, Jul 18, 2015 at 12:14 AM, Martin Wierschin wrote: >> >> I just had a beta tester contact me about a very similar error/crash. It's >> slightly different than I've seen before, but it certainly seems related. >> >> The tester was closing a window backed by NSDocument. In response the >> AppKit document machinery was attempting to create an NSSavePanel, to allow >> the user to save or discard the file, but NSRemoteView threw an >> exception[1]. >> >> As I mentioned earlier in this thread, I've come to anticipate this. I now >> wrap the relevant NSDocument method to catch any exceptions and display a >> warning alert that the system save panel is (apparently) temporarily >> unavailable. This time the app crashed while trying to generate that alert; >> -[NSAlert init] was loading some localized string and crashed[2]. >> >> I doubt this is going to be reproducible, but it's reported as >> rdar://21881669. >> >> ~Martin Wierschin >> >> >> [1] INITIAL EXCEPTION: >> >> MyApp[807]: *** Assertion failure in -[NSRemoteView >> setServiceObject:forKey:], >> /SourceCache/ViewBridge/ViewBridge-105/NSRemoteView.m:3142 >>failed: invalid >>in: NSInternalInconsistencyException line 0 >>STACK TRACE: >> ... >> libobjc.A.dylib objc_exception_throw >> CoreFoundation+[NSException raise:format:arguments:] >> Foundation-[NSAssertionHandler >> handleFailureInMethod:object:file:lineNumber:description:] >> ViewBridge-[NSRemoteViewBase setServiceObject:forKey:] >> FoundationNSKeyValueNotifyObserver >> FoundationNSKeyValueDidChange >> Foundation-[NSObject(NSKeyValueObserverNotification) >> didChangeValueForKey:] >> AppKit-[NSDocument _preparedSavePanelForOperation:] >> ... >> AppKit-[NSDocument >> canCloseDocumentWithDelegate:shouldCloseSelector:contextInfo:] >> AppKit-[NSWindow __close] >> AppKit-[NSControl sendAction:to:] >> ... >> AppKitNSApplicationMain >> MyApp MyAppMain >> MyApp start >> >> >> >> [2] SUBSEQUENT CRASH: >> >> Exception Typ
Re: Safe time to add accessory view to NSSavePanel in sandboxed app?
I just went through my crashes and this thread popped up in google. I have additional information (one helpful method in the stack). Even if I dig deep I still can't figure out what can cause the issue. Is anyone able to get from "_hierarchyDidChangeInView" the line where it crashes? Anyway I created rdar://23165196 Marek. Date/Time: 2015-10-14T19:16:34Z OS Version: Mac OS X 10.11.0 (15A278b) Report Version: 104 Exception Type: SIGSEGV Exception Codes: SEGV_MAPERR at 0x7fc7a764438 Crashed Thread: 0 Thread 0 Crashed: 0 libobjc.A.dylib 0x7fff84dcbe5d objc_msgSend + 29 1 ViewBridge 0x7fff9519ea42 -[NSVBAccessoryWindow _hierarchyDidChangeInView:] + 69 2 AppKit 0x7fff86593aea -[NSView _setSuperview:] + 2602 3 AppKit 0x7fff86592c28 -[NSView addSubview:] + 448 4 AppKit 0x7fff865fa754 -[NSWindow setContentView:] + 638 5 ViewBridge 0x7fff951d1253 setWindowContentView + 75 6 ViewBridge 0x7fff951b5d8b -[NSRemoteViewBase setAccessoryView:] + 208 7 AppKit 0x7fff86df9ed8 -[NSVBSavePanel(NSSavePanelSPI) _sendAccessoryView:] + 49 80x00010b56e3b0 0x10b4bf000 + 717744 On Sat, Jul 18, 2015 at 12:14 AM, Martin Wierschin wrote: > I just had a beta tester contact me about a very similar error/crash. It's > slightly different than I've seen before, but it certainly seems related. > > The tester was closing a window backed by NSDocument. In response the > AppKit document machinery was attempting to create an NSSavePanel, to allow > the user to save or discard the file, but NSRemoteView threw an > exception[1]. > > As I mentioned earlier in this thread, I've come to anticipate this. I now > wrap the relevant NSDocument method to catch any exceptions and display a > warning alert that the system save panel is (apparently) temporarily > unavailable. This time the app crashed while trying to generate that alert; > -[NSAlert init] was loading some localized string and crashed[2]. > > I doubt this is going to be reproducible, but it's reported as > rdar://21881669. > > ~Martin Wierschin > > > [1] INITIAL EXCEPTION: > > MyApp[807]: *** Assertion failure in -[NSRemoteView > setServiceObject:forKey:], > /SourceCache/ViewBridge/ViewBridge-105/NSRemoteView.m:3142 > failed: invalid > in: NSInternalInconsistencyException line 0 > STACK TRACE: > ... > libobjc.A.dylib objc_exception_throw > CoreFoundation+[NSException raise:format:arguments:] > Foundation-[NSAssertionHandler > handleFailureInMethod:object:file:lineNumber:description:] > ViewBridge-[NSRemoteViewBase setServiceObject:forKey:] > FoundationNSKeyValueNotifyObserver > FoundationNSKeyValueDidChange > Foundation-[NSObject(NSKeyValueObserverNotification) > didChangeValueForKey:] > AppKit-[NSDocument _preparedSavePanelForOperation:] > ... > AppKit-[NSDocument > canCloseDocumentWithDelegate:shouldCloseSelector:contextInfo:] > AppKit-[NSWindow __close] > AppKit-[NSControl sendAction:to:] > ... > AppKitNSApplicationMain > MyApp MyAppMain > MyApp start > > > > [2] SUBSEQUENT CRASH: > > Exception Type:EXC_BAD_ACCESS (SIGSEGV) > Exception Codes: KERN_INVALID_ADDRESS atVM Regions Near: > ... > Thread 0 Crashed:: Dispatch queue: com.apple.main-thread > 0 com.apple.CoreServices.CarbonCore _CSGetNamedData > 1 com.apple.CoreFoundation _CFPropertyListCopyShared > 2 com.apple.CoreFoundation > CFBundleCopyLocalizedStringForLocalization > 3 com.apple.Foundation -[NSBundle > localizedStringForKey:value:table:] > 4 com.apple.AppKit -[NSAlert init] > 5 com.apple.AppKit +[NSAlert > alertWithMessageText:defaultButton:alternateButton:otherButton:informativeTextWithFormat:] > 6 com.company.myapp __84-[MyApp > delayedWarnAboutUnavailableSavePanel:]_block_invoke > 7 libdispatch.dylib _dispatch_call_block_and_release > 8 libdispatch.dylib _dispatch_client_callout > ... > 17 com.apple.AppKit -[NSApplication > nextEventMatchingMask:untilDate:inMode:dequeue:] > 18 com.apple.AppKit -[NSApplication run] > 19 com.apple.AppKit NSApplicationMain > 20 com.company.myapp MyMain
Re: Safe time to add accessory view to NSSavePanel in sandboxed app?
I just had a beta tester contact me about a very similar error/crash. It's slightly different than I've seen before, but it certainly seems related. The tester was closing a window backed by NSDocument. In response the AppKit document machinery was attempting to create an NSSavePanel, to allow the user to save or discard the file, but NSRemoteView threw an exception[1]. As I mentioned earlier in this thread, I've come to anticipate this. I now wrap the relevant NSDocument method to catch any exceptions and display a warning alert that the system save panel is (apparently) temporarily unavailable. This time the app crashed while trying to generate that alert; -[NSAlert init] was loading some localized string and crashed[2]. I doubt this is going to be reproducible, but it's reported as rdar://21881669. ~Martin Wierschin [1] INITIAL EXCEPTION: MyApp[807]: *** Assertion failure in -[NSRemoteView setServiceObject:forKey:], /SourceCache/ViewBridge/ViewBridge-105/NSRemoteView.m:3142 failed: invalid in: NSInternalInconsistencyException line 0 STACK TRACE: ... libobjc.A.dylib objc_exception_throw CoreFoundation+[NSException raise:format:arguments:] Foundation-[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] ViewBridge-[NSRemoteViewBase setServiceObject:forKey:] FoundationNSKeyValueNotifyObserver FoundationNSKeyValueDidChange Foundation-[NSObject(NSKeyValueObserverNotification) didChangeValueForKey:] AppKit-[NSDocument _preparedSavePanelForOperation:] ... AppKit-[NSDocument canCloseDocumentWithDelegate:shouldCloseSelector:contextInfo:] AppKit-[NSWindow __close] AppKit-[NSControl sendAction:to:] ... AppKitNSApplicationMain MyApp MyAppMain MyApp start [2] SUBSEQUENT CRASH: Exception Type:EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS atVM Regions Near: ... Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 com.apple.CoreServices.CarbonCore _CSGetNamedData 1 com.apple.CoreFoundation _CFPropertyListCopyShared 2 com.apple.CoreFoundation CFBundleCopyLocalizedStringForLocalization 3 com.apple.Foundation -[NSBundle localizedStringForKey:value:table:] 4 com.apple.AppKit -[NSAlert init] 5 com.apple.AppKit +[NSAlert alertWithMessageText:defaultButton:alternateButton:otherButton:informativeTextWithFormat:] 6 com.company.myapp __84-[MyApp delayedWarnAboutUnavailableSavePanel:]_block_invoke 7 libdispatch.dylib _dispatch_call_block_and_release 8 libdispatch.dylib _dispatch_client_callout ... 17 com.apple.AppKit -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] 18 com.apple.AppKit -[NSApplication run] 19 com.apple.AppKit NSApplicationMain 20 com.company.myapp MyMain 21 com.company.myapp start ___ 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: Safe time to add accessory view to NSSavePanel in sandboxed app?
> On 17 Jul 2015, at 6:20 am, Mike Abdullah wrote: > >>> Is it trying to be clever and re-use existing accessory views, or is a >>> fresh one created each time? >> >> Why do you ask? Is this a known problem? > > My thinking is _setSuperview: seems somewhat a surprising place to crash. > > I’m hazarding a guess that the accessory view is not a fresh one, and still > has a reference to its previous superview. Apple’s code doesn’t expect that > situation, and finds the pointer to the previous superview to be invalid > perhaps. > > This is Apple’s bug, but if my guess is correct, you could probably work > around it by manually _removing_ your accessory view from NSSavePanel once > the panel returns, rather than leaving semi-attached there. In my case the accessory view is reused, in that it’s defined in a nib and referenced by an outlet. I keep a strong reference to it so it is ‘owned’ by the controller, and added to each save panel as needed. I’m not doing anything special to clean up when I’m done with the save panel - I’ll look into whether manually removing it and/or clearing the superview reference fixes the problem. —Graham ___ 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: Safe time to add accessory view to NSSavePanel in sandboxed app?
That logic makes good sense Mike. Unfortunately it doesn't seem to avert the crash. My own app, which still encounters this crash from time to time, actually already does what you suggest: after the save operation has been completed, the accessory view removes itself from the NSSavePanel by calling [panel setAccessoryView:nil]. And after reviewing my code, it turns out that my app doesn't recycle/reuse accessory view instances after all. I thought it still did, but that was some time ago, when the open/save panels were slow as death under sandboxing. ~Martin Wierschin > My thinking is _setSuperview: seems somewhat a surprising place to crash. > > I’m hazarding a guess that the accessory view is not a fresh one, and still > has a reference to its previous superview. Apple’s code doesn’t expect that > situation, and finds the pointer to the previous superview to be invalid > perhaps. > > This is Apple’s bug, but if my guess is correct, you could probably work > around it by manually _removing_ your accessory view from NSSavePanel once > the panel returns, rather than leaving semi-attached there. > ___ 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: Safe time to add accessory view to NSSavePanel in sandboxed app?
> On 16 Jul 2015, at 20:30, Martin Wierschin wrote: > >>> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread >>> 0 libobjc.A.dylib 0x7fff8b5b80dd objc_msgSend + 29 >>> 1 com.apple.AppKit0x7fff9231bb94 -[NSView >>> _setSuperview:] + 2591 >>> 2 com.apple.AppKit0x7fff9231ad78 -[NSView >>> addSubview:] + 436 >>> 3 com.apple.AppKit0x7fff92346432 -[NSWindow >>> setContentView:] + 640 >>> 4 com.apple.ViewBridge0x7fff93d460c1 setWindowContentView >>> + 75 >>> 5 com.apple.ViewBridge0x7fff93d34d42 -[NSRemoteViewBase >>> setAccessoryView:] + 208 >>> 60x00010ba36a1d 0x10b9ab000 >>> + 571933 > >> Is it trying to be clever and re-use existing accessory views, or is a fresh >> one created each time? > > Why do you ask? Is this a known problem? My thinking is _setSuperview: seems somewhat a surprising place to crash. I’m hazarding a guess that the accessory view is not a fresh one, and still has a reference to its previous superview. Apple’s code doesn’t expect that situation, and finds the pointer to the previous superview to be invalid perhaps. This is Apple’s bug, but if my guess is correct, you could probably work around it by manually _removing_ your accessory view from NSSavePanel once the panel returns, rather than leaving semi-attached there. ___ 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: Safe time to add accessory view to NSSavePanel in sandboxed app?
I've also seen this crash, as reported by users of my own sandboxed app, though I've never reproduced it myself. I've also seen other situations where NSSavePanel and NSOpenPanel trigger XPC assertions/exceptions. For example: > *** Assertion failure in +[NSXPCSharedListener > connectionForListenerNamed:fromServiceNamed:], > /SourceCache/ViewBridge/ViewBridge-105/NSXPCSharedListener.m:394 > NSXPCSharedListener unable to create endpoint for listener named > com.apple.view-bridge In this situation an instance of NSSavePanel simply could not be created, before my accessory view was even requested. This would deadlock my app as the NSDocument machinery tried to initiate a save operation– filed as rdar://21128102. I managed to prevent the deadlock by catching the exception, canceling the save, and alerting the user that OSX's save panel was temporarily unavailable. Not the most reassuring of error messages, but better than a hang. There were a lot of these issues under OSX 10.9. For example -[NSRemoteView updateWindowEdgeResizingRegion] would trigger: > is invalid; in: > NSInternalInconsistencyException line 0. They seemed harmless enough, but filled console logs. I haven't seen them as often lately, so hopefully things are improving. > Is it trying to be clever and re-use existing accessory views, or is a fresh > one created each time? Why do you ask? Is this a known problem? The Apple documentation implies that it's safe, as long as you handle the memory management properly: > If you want to reuse the accessory view, you should not rely on the panel to > hold onto the accessory view until the next time you use it; instead, you > should maintain your own strong reference to the view. ~Martin Wierschin ___ 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: Safe time to add accessory view to NSSavePanel in sandboxed app?
> On 16 Jul 2015, at 02:33, Graham Cox wrote: > > > Pertinent details below - the line marked contains the code > listed previously, which is an action method invoked by a menu command. > > > Date/Time: 2015-07-15 10:32:36.027 -0400 > OS Version:Mac OS X 10.10.4 (14E46) > Report Version:11 > Anonymous UUID:2614ADC0-4001-6CA3-540E-6108024E52C9 > > Sleep/Wake UUID: 473E70D2-38EF-44CC-B867-61044E46EA90 > > Time Awake Since Boot: 19 seconds > Time Since Wake: 2600 seconds > > Crashed Thread:0 Dispatch queue: com.apple.main-thread > > Exception Type:EXC_BAD_ACCESS (SIGSEGV) > Exception Codes: KERN_INVALID_ADDRESS at 0x07f9a74a1988 > > VM Regions Near 0x7f9a74a1988: >MALLOC_LARGE 00012db2b000-00012dd27000 [ 2032K] rw-/rwx > SM=PRV > --> >__TEXT 1234-1234004a5000 [ 4756K] r-x/rwx > SM=COW > /System/Library/Extensions/AppleIntelHD4000GraphicsGLDriver.bundle/Contents/MacOS/AppleIntelHD4000GraphicsGLDriver > > Application Specific Information: > objc_msgSend() selector name: invalid > Performing @selector(exportAction:) from sender NSMenuItem 0x7f9a69c27d20 > > Thread 0 Crashed:: Dispatch queue: com.apple.main-thread > 0 libobjc.A.dylib 0x7fff8b5b80dd objc_msgSend + 29 > 1 com.apple.AppKit 0x7fff9231bb94 -[NSView > _setSuperview:] + 2591 > 2 com.apple.AppKit 0x7fff9231ad78 -[NSView > addSubview:] + 436 > 3 com.apple.AppKit 0x7fff92346432 -[NSWindow > setContentView:] + 640 > 4 com.apple.ViewBridge 0x7fff93d460c1 setWindowContentView > + 75 > 5 com.apple.ViewBridge 0x7fff93d34d42 -[NSRemoteViewBase > setAccessoryView:] + 208 > 6 0x00010ba36a1d 0x10b9ab000 > + 571933 > 7 libsystem_trace.dylib 0x7fff8ba8acd7 > _os_activity_initiate + 75 > 8 com.apple.AppKit 0x7fff92530eb1 -[NSApplication > sendAction:to:from:] + 452 > 9 com.apple.AppKit 0x7fff92530c4e -[NSMenuItem > _corePerformAction] + 382 > 10 com.apple.AppKit 0x7fff9253097c -[NSCarbonMenuImpl > performActionWithHighlightingForItemAtIndex:] + 114 > 11 libsystem_trace.dylib 0x7fff8ba8acd7 > _os_activity_initiate + 75 > 12 com.apple.AppKit 0x7fff925f7b00 -[NSMenu > performActionForItemAtIndex:] + 131 > 13 com.apple.AppKit 0x7fff925f7a66 -[NSMenu > _internalPerformActionForItemAtIndex:] + 35 > 14 com.apple.AppKit 0x7fff925f78b2 -[NSCarbonMenuImpl > _carbonCommandProcessEvent:handlerCallRef:] + 107 > 15 com.apple.AppKit 0x7fff92518d6b > NSSLMMenuEventHandler + 724 > 16 com.apple.HIToolbox 0x7fff8bc12b6c > DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + > 1260 > 17 com.apple.HIToolbox 0x7fff8bc11fae > SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, > HandlerCallRec*) + 386 > 18 com.apple.HIToolbox 0x7fff8bc27cb6 > SendEventToEventTarget + 40 > 19 com.apple.HIToolbox 0x7fff8bc61f45 > SendHICommandEvent(unsigned int, HICommand const*, unsigned int, unsigned > int, unsigned char, void const*, OpaqueEventTargetRef*, > OpaqueEventTargetRef*, OpaqueEventRef**) + 428 > 20 com.apple.HIToolbox 0x7fff8bc9fb8d > SendMenuCommandWithContextAndModifiers + 59 > 21 com.apple.HIToolbox 0x7fff8bc9fb30 > SendMenuItemSelectedEvent + 188 > 22 com.apple.HIToolbox 0x7fff8bc9fa09 > FinishMenuSelection(SelectionData*, MenuResult*, MenuResult*) + 96 > 23 com.apple.HIToolbox 0x7fff8bca0481 > MenuSelectCore(MenuData*, Point, double, unsigned int, OpaqueMenuRef**, > unsigned short*) + 702 > 24 com.apple.HIToolbox 0x7fff8bca00fe > _HandleMenuSelection2 + 446 > 25 com.apple.AppKit 0x7fff92436ce0 > _NSHandleCarbonMenuEvent + 277 > 26 com.apple.AppKit 0x7fff9236dbfd _DPSNextEvent + 1828 > 27 com.apple.AppKit 0x7fff9236ce58 -[NSApplication > nextEventMatchingMask:untilDate:inMode:dequeue:] + 346 > 28 com.apple.AppKit 0x7fff92362af3 -[NSApplication run] > + 594 > 29 com.apple.AppKit 0x7fff922df244 NSApplicationMain + > 1832 What does your code for setting the accessory view look like? Is it trying to be clever and re-use existing accessory views, or is a fresh one created each time? ___ 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/U
Re: Safe time to add accessory view to NSSavePanel in sandboxed app?
> On 16 Jul 2015, at 11:01 am, Conrad Shultz wrote: > > >> On Jul 15, 2015, at 3:53 PM, Graham Cox wrote: >> >> This works 99% of the time, but sometimes it just crashes. This seems to >> occur when the app has just been activated after using a different app, and >> this save panel is requested within a few seconds of the activation, though >> that’s a bit of a woolly description because the circumstances make it >> difficult to reproduce reliably. > > Do you have a crash log? > > -Conrad Pertinent details below - the line marked contains the code listed previously, which is an action method invoked by a menu command. Date/Time: 2015-07-15 10:32:36.027 -0400 OS Version:Mac OS X 10.10.4 (14E46) Report Version:11 Anonymous UUID:2614ADC0-4001-6CA3-540E-6108024E52C9 Sleep/Wake UUID: 473E70D2-38EF-44CC-B867-61044E46EA90 Time Awake Since Boot: 19 seconds Time Since Wake: 2600 seconds Crashed Thread:0 Dispatch queue: com.apple.main-thread Exception Type:EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x07f9a74a1988 VM Regions Near 0x7f9a74a1988: MALLOC_LARGE 00012db2b000-00012dd27000 [ 2032K] rw-/rwx SM=PRV --> __TEXT 1234-1234004a5000 [ 4756K] r-x/rwx SM=COW /System/Library/Extensions/AppleIntelHD4000GraphicsGLDriver.bundle/Contents/MacOS/AppleIntelHD4000GraphicsGLDriver Application Specific Information: objc_msgSend() selector name: invalid Performing @selector(exportAction:) from sender NSMenuItem 0x7f9a69c27d20 Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libobjc.A.dylib 0x7fff8b5b80dd objc_msgSend + 29 1 com.apple.AppKit0x7fff9231bb94 -[NSView _setSuperview:] + 2591 2 com.apple.AppKit0x7fff9231ad78 -[NSView addSubview:] + 436 3 com.apple.AppKit0x7fff92346432 -[NSWindow setContentView:] + 640 4 com.apple.ViewBridge0x7fff93d460c1 setWindowContentView + 75 5 com.apple.ViewBridge0x7fff93d34d42 -[NSRemoteViewBase setAccessoryView:] + 208 60x00010ba36a1d 0x10b9ab000 + 571933 7 libsystem_trace.dylib 0x7fff8ba8acd7 _os_activity_initiate + 75 8 com.apple.AppKit0x7fff92530eb1 -[NSApplication sendAction:to:from:] + 452 9 com.apple.AppKit0x7fff92530c4e -[NSMenuItem _corePerformAction] + 382 10 com.apple.AppKit0x7fff9253097c -[NSCarbonMenuImpl performActionWithHighlightingForItemAtIndex:] + 114 11 libsystem_trace.dylib 0x7fff8ba8acd7 _os_activity_initiate + 75 12 com.apple.AppKit0x7fff925f7b00 -[NSMenu performActionForItemAtIndex:] + 131 13 com.apple.AppKit0x7fff925f7a66 -[NSMenu _internalPerformActionForItemAtIndex:] + 35 14 com.apple.AppKit0x7fff925f78b2 -[NSCarbonMenuImpl _carbonCommandProcessEvent:handlerCallRef:] + 107 15 com.apple.AppKit0x7fff92518d6b NSSLMMenuEventHandler + 724 16 com.apple.HIToolbox 0x7fff8bc12b6c DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 1260 17 com.apple.HIToolbox 0x7fff8bc11fae SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) + 386 18 com.apple.HIToolbox 0x7fff8bc27cb6 SendEventToEventTarget + 40 19 com.apple.HIToolbox 0x7fff8bc61f45 SendHICommandEvent(unsigned int, HICommand const*, unsigned int, unsigned int, unsigned char, void const*, OpaqueEventTargetRef*, OpaqueEventTargetRef*, OpaqueEventRef**) + 428 20 com.apple.HIToolbox 0x7fff8bc9fb8d SendMenuCommandWithContextAndModifiers + 59 21 com.apple.HIToolbox 0x7fff8bc9fb30 SendMenuItemSelectedEvent + 188 22 com.apple.HIToolbox 0x7fff8bc9fa09 FinishMenuSelection(SelectionData*, MenuResult*, MenuResult*) + 96 23 com.apple.HIToolbox 0x7fff8bca0481 MenuSelectCore(MenuData*, Point, double, unsigned int, OpaqueMenuRef**, unsigned short*) + 702 24 com.apple.HIToolbox 0x7fff8bca00fe _HandleMenuSelection2 + 446 25 com.apple.AppKit0x7fff92436ce0 _NSHandleCarbonMenuEvent + 277 26 com.apple.AppKit0x7fff9236dbfd _DPSNextEvent + 1828 27 com.apple.AppKit0x7fff9236ce58 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 346 28 com.apple.AppKit0x7fff92362af3 -[NSApplication run] + 594 29 com.apple.AppKit0x7fff922df244 NSApplicationMain + 1832 ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Re: Safe time to add accessory view to NSSavePanel in sandboxed app?
> On Jul 15, 2015, at 3:53 PM, Graham Cox wrote: > > This works 99% of the time, but sometimes it just crashes. This seems to > occur when the app has just been activated after using a different app, and > this save panel is requested within a few seconds of the activation, though > that’s a bit of a woolly description because the circumstances make it > difficult to reproduce reliably. Do you have a crash log? -Conrad ___ 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
Safe time to add accessory view to NSSavePanel in sandboxed app?
In a sandboxed app, I do: NSSavePanel* sp = [NSSavePanel savePanel]; [sp setAccessoryView:some_view]; This works 99% of the time, but sometimes it just crashes. This seems to occur when the app has just been activated after using a different app, and this save panel is requested within a few seconds of the activation, though that’s a bit of a woolly description because the circumstances make it difficult to reproduce reliably. Has anyone run into this? Is there a better way or time to set the accessory view so any race condition (as this might imply) has had time to sort itself out? —Graham ___ 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: NSSavePanel load error
thanks for your speedy reply lee ann! pleased someone else thinks it a bug. cheers, edward ps: that should have read: ‘i have not sub-calssed NSSavePanel’. > On Oct 27, 2014, at 3:49 PM, Lee Ann Rucker wrote: > > Apple bug - according to classdump, that class has had a “layout” method > since before autolayout even existed, and I know from experience it doesn’t > grok autolayout. > > You can ignore it. > > On Oct 27, 2014, at 11:56 AM, edward taffel <mailto:etaf...@me.com>> wrote: > >> just updated my dev machine to yosemite. closing a document window >> (command-W) from within my app, causes the following log: >> >> [NSSavePanelAlertStyleContentView layout]. NSSavePanelAlertStyleContentView >> or one of its superclasses may have overridden -layout without calling >> super. Or, something may have dirtied layout in the middle of updating it. >> Both are programming errors in Cocoa Autolayout. The former is pretty >> likely to arise if some pre-Cocoa Autolayout class had a method called >> layout, but it should be fixed. >> >> i have not sub-calsses NSSavePanel & this only occurs on the first >> NSSavePanel load; further close commands do not cause the message to be >> emitted. >> >> anyone else seeing this? bug or something else? >> ___ >> >> 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://urldefense.proofpoint.com/v1/url?u=https://lists.apple.com/mailman/options/cocoa-dev/lrucker%2540vmware.com&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=yJFJhaNnTZDfFSSz1U9TSNMmxGyib3KjZGuKfIhHLxA%3D%0A&m=2fRU3%2B4qYUxqZQLWCyGxoBTKmSk4KxHw%2FOYND39I3X0%3D%0A&s=05dba73cdd69425793a5572aebaf6dcfc23e3641bb4976e18e32958a9c2d0cfa >> >> <https://urldefense.proofpoint.com/v1/url?u=https://lists.apple.com/mailman/options/cocoa-dev/lrucker%2540vmware.com&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=yJFJhaNnTZDfFSSz1U9TSNMmxGyib3KjZGuKfIhHLxA%3D%0A&m=2fRU3%2B4qYUxqZQLWCyGxoBTKmSk4KxHw%2FOYND39I3X0%3D%0A&s=05dba73cdd69425793a5572aebaf6dcfc23e3641bb4976e18e32958a9c2d0cfa> >> >> This email sent to lruc...@vmware.com <mailto:lruc...@vmware.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: NSSavePanel load error
Apple bug - according to classdump, that class has had a “layout” method since before autolayout even existed, and I know from experience it doesn’t grok autolayout. You can ignore it. On Oct 27, 2014, at 11:56 AM, edward taffel wrote: > just updated my dev machine to yosemite. closing a document window > (command-W) from within my app, causes the following log: > > [NSSavePanelAlertStyleContentView layout]. NSSavePanelAlertStyleContentView > or one of its superclasses may have overridden -layout without calling super. > Or, something may have dirtied layout in the middle of updating it. Both are > programming errors in Cocoa Autolayout. The former is pretty likely to arise > if some pre-Cocoa Autolayout class had a method called layout, but it should > be fixed. > > i have not sub-calsses NSSavePanel & this only occurs on the first > NSSavePanel load; further close commands do not cause the message to be > emitted. > > anyone else seeing this? bug or something else? > ___ > > 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://urldefense.proofpoint.com/v1/url?u=https://lists.apple.com/mailman/options/cocoa-dev/lrucker%2540vmware.com&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=yJFJhaNnTZDfFSSz1U9TSNMmxGyib3KjZGuKfIhHLxA%3D%0A&m=2fRU3%2B4qYUxqZQLWCyGxoBTKmSk4KxHw%2FOYND39I3X0%3D%0A&s=05dba73cdd69425793a5572aebaf6dcfc23e3641bb4976e18e32958a9c2d0cfa > > This email sent to lruc...@vmware.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
NSSavePanel load error
just updated my dev machine to yosemite. closing a document window (command-W) from within my app, causes the following log: [NSSavePanelAlertStyleContentView layout]. NSSavePanelAlertStyleContentView or one of its superclasses may have overridden -layout without calling super. Or, something may have dirtied layout in the middle of updating it. Both are programming errors in Cocoa Autolayout. The former is pretty likely to arise if some pre-Cocoa Autolayout class had a method called layout, but it should be fixed. i have not sub-calsses NSSavePanel & this only occurs on the first NSSavePanel load; further close commands do not cause the message to be emitted. anyone else seeing this? bug or something else? ___ 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
MODERATOR: End of Thread (was Re: NSSavePanel?)
This is off-topic for cocoa-dev. -- Chris Hanson, cocoa-dev co-moderator ___ 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: NSSavePanel?
On Mar 6, 2014, at 4:18 PM, Todd Heberlein wrote: > Not sure if this is directly related, but… > > When a non-sandboxed application presents the Open or Save panel, the program > starts opening files in the currently selected directory. Move to a different > directory, and the application will start pounding on the files in that > directory. This seems to be the case with most (all?) non-sandboxed apps, so > it is probably part of the Apple library code. This is a pain in the butt for > me when I do audit trail analysis. > > Sandboxed applications don’t do this. An Apple daemon does this on the > application’s behalf (presumably the “power box”), but from a security point > of view, this is much easier to analyze. I encourage developers and users to > move to sandboxed apps ASAP. :) Well, we all would, if it wasn’t such an occasional pain in the ass. > > For a detailed video on this problem, see > > Data Fence: Audit Data vs. Last Access Time > http://www.toddheberlein.com/videos/2014/1/27/data-fence-audit-data-vs-last-access-time > > Todd > > > On Mar 6, 2014, at 11:20 AM, livinginlosange...@mac.com wrote: > >> What’s Adobe’s beef with NSSavePanel? I found this while running fs_usage on >> my computer. >> >> Adobe Easter Egg? >> >> 11:14:46 getattrlist /Volumes/DriveA/030514 0.14 Adobe >> Photos >> 11:14:46 getattrlist es/DriveA/030514/TestSave0.10 Adobe >> Photos >> 11:14:46 lstat64 __NSSAVEPANEL_IS_SO_L.AME0.07 Adobe >> Photos >> 11:14:46 lstat64 es/DriveA/030514/TestSave0.11 Adobe >> Photos >> 11:14:46 getattrlist es/DriveA/030514/TestSave0.07 Adobe >> Photos >> 11:14:46 lstat64 __NSSAVEPANEL_IS_SO_L.AME0.06 Adobe >> Photos >> 11:14:46 getattrlist __NSSAVEPANEL_IS_SO_L.AME0.04 Adobe >> Photos >> 11:14:46 write 0.24 >> screensharin >> 11:14:46 select 0.250128 W >> netsession_m >> 11:14:46 getattrlist es/DriveA/030514/TestSave0.15 Adobe >> Photos >> 11:14:46 getattrlist es/DriveA/030514/TestSave0.06 Adobe >> Photos >> 11:14:46 getattrlist /Volumes/DriveA/030514 0.07 Adobe >> Photos >> 11:14:46 getattrlist es/DriveA/030514/TestSave0.06 Adobe >> Photos >> 11:14:46 getattrlist es/DriveA/030514/TestSave0.05 Adobe >> Photos >> 11:14:46 write 0.17 >> screensharin >> 11:14:46 getattrlist TESTSAVE_2.psd 0.13 Adobe >> Photos >> ___ >> >> 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/todd_heberlein%40mac.com >> >> This email sent to todd_heberl...@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/sevenbitstech%40gmail.com > > This email sent to sevenbitst...@gmail.com signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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: NSSavePanel?
Not sure if this is directly related, but… When a non-sandboxed application presents the Open or Save panel, the program starts opening files in the currently selected directory. Move to a different directory, and the application will start pounding on the files in that directory. This seems to be the case with most (all?) non-sandboxed apps, so it is probably part of the Apple library code. This is a pain in the butt for me when I do audit trail analysis. Sandboxed applications don’t do this. An Apple daemon does this on the application’s behalf (presumably the “power box”), but from a security point of view, this is much easier to analyze. I encourage developers and users to move to sandboxed apps ASAP. :) For a detailed video on this problem, see Data Fence: Audit Data vs. Last Access Time http://www.toddheberlein.com/videos/2014/1/27/data-fence-audit-data-vs-last-access-time Todd On Mar 6, 2014, at 11:20 AM, livinginlosange...@mac.com wrote: > What’s Adobe’s beef with NSSavePanel? I found this while running fs_usage on > my computer. > > Adobe Easter Egg? > > 11:14:46 getattrlist /Volumes/DriveA/030514 0.14 Adobe > Photos > 11:14:46 getattrlist es/DriveA/030514/TestSave0.10 Adobe > Photos > 11:14:46 lstat64 __NSSAVEPANEL_IS_SO_L.AME0.07 Adobe > Photos > 11:14:46 lstat64 es/DriveA/030514/TestSave0.11 Adobe > Photos > 11:14:46 getattrlist es/DriveA/030514/TestSave0.07 Adobe > Photos > 11:14:46 lstat64 __NSSAVEPANEL_IS_SO_L.AME0.06 Adobe > Photos > 11:14:46 getattrlist __NSSAVEPANEL_IS_SO_L.AME0.04 Adobe > Photos > 11:14:46 write 0.24 > screensharin > 11:14:46 select 0.250128 W > netsession_m > 11:14:46 getattrlist es/DriveA/030514/TestSave0.15 Adobe > Photos > 11:14:46 getattrlist es/DriveA/030514/TestSave0.06 Adobe > Photos > 11:14:46 getattrlist /Volumes/DriveA/030514 0.07 Adobe > Photos > 11:14:46 getattrlist es/DriveA/030514/TestSave0.06 Adobe > Photos > 11:14:46 getattrlist es/DriveA/030514/TestSave0.05 Adobe > Photos > 11:14:46 write 0.17 > screensharin > 11:14:46 getattrlist TESTSAVE_2.psd 0.13 Adobe > Photos > ___ > > 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/todd_heberlein%40mac.com > > This email sent to todd_heberl...@mac.com signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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: NSSavePanel?
On Thu, Mar 6, 2014, at 11:20 AM, livinginlosange...@mac.com wrote: > What’s Adobe’s beef with NSSavePanel? I found this while running fs_usage > on my computer. > > Adobe Easter Egg? No clue, but this thread isn't going to provide any useful discussion. --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
NSSavePanel?
What’s Adobe’s beef with NSSavePanel? I found this while running fs_usage on my computer. Adobe Easter Egg? 11:14:46 getattrlist /Volumes/DriveA/030514 0.14 Adobe Photos 11:14:46 getattrlist es/DriveA/030514/TestSave0.10 Adobe Photos 11:14:46 lstat64 __NSSAVEPANEL_IS_SO_L.AME0.07 Adobe Photos 11:14:46 lstat64 es/DriveA/030514/TestSave0.11 Adobe Photos 11:14:46 getattrlist es/DriveA/030514/TestSave0.07 Adobe Photos 11:14:46 lstat64 __NSSAVEPANEL_IS_SO_L.AME0.06 Adobe Photos 11:14:46 getattrlist __NSSAVEPANEL_IS_SO_L.AME0.04 Adobe Photos 11:14:46 write 0.24 screensharin 11:14:46 select 0.250128 W netsession_m 11:14:46 getattrlist es/DriveA/030514/TestSave0.15 Adobe Photos 11:14:46 getattrlist es/DriveA/030514/TestSave0.06 Adobe Photos 11:14:46 getattrlist /Volumes/DriveA/030514 0.07 Adobe Photos 11:14:46 getattrlist es/DriveA/030514/TestSave0.06 Adobe Photos 11:14:46 getattrlist es/DriveA/030514/TestSave0.05 Adobe Photos 11:14:46 write 0.17 screensharin 11:14:46 getattrlist TESTSAVE_2.psd 0.13 Adobe Photos ___ 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: NSSavePanel problem with sandboxing
On Fri, Sep 6, 2013, at 08:16 AM, Manfred Schwind wrote: > > the pointer value for the save panel never changes, but the object it > > points to has some serious changes of identity. > > For me this sounds like an "overrelease" or "access after release" > problem. > You could try to run with enabled zombie objects. What? No. There is no bug here. If your app is sandboxed, each NSSavePanel instance swaps out its implementation at runtime, based on whether Powerbox is showing the out-of-process save panel. --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: NSSavePanel problem with sandboxing
> the pointer value for the save panel never changes, but the object it points > to has some serious changes of identity. For me this sounds like an "overrelease" or "access after release" problem. You could try to run with enabled zombie objects. Regards, Mani ___ 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: NSSavePanel problem with sandboxing
On 06/09/2013, at 1:33 AM, Fritz Anderson wrote: > The next thing I'd do is to see if the protocol would be of any > comfort. I think it may even be preferred to resetting the window's first > responder. It's never been clear to me how that protocol is implemented with respect to dialogs, or windows in general. It's implemented by NSController, which is not inherited by NSWindowController, and even if it were, NSSavePanel doesn't appear to have a window controller. If it's implemented by individual text fields, that means I'd have to track which text field is active, which is a bunch of extra work I don't usually have to bother with. Or do I send it to the field editor? I can find no documentation that really explains how the protocol should be used in practice, and in any case it seems to be something to do with bindings, which I'm not using here. That's why I've tended to stick with the tried and tested and above all, simple method of simply setting FR to the window when I need any pending fields to commit. I would like to know what I *should* be doing though. --Graham ___ 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: NSSavePanel problem with sandboxing
On 05/09/2013, at 8:54 PM, Kyle Sluder wrote: > What happens if you ask one of your accessory controls for its -window > and ask _that_ object to -makeFirstResponder:? That window should be in > your own process. Works on 10.8, but in fact the control's window is the same object as the save panel. That makes sense, since I found the "well-defined times" note I remembered, it's in the 10.8 release notes. The completion block is indeed a valid time, but that isn't the case on 10.7. The mind boggles at the hacks being pulled behind the scenes here - the pointer value for the save panel never changes, but the object it points to has some serious changes of identity. Testing this on 10.7 is difficult, so I won't know if it works there for a while, but here's hoping…. thanks :) --Graham ___ 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: NSSavePanel problem with sandboxing
On Thu, Sep 5, 2013, at 11:33 AM, Graham Cox wrote: > > On 05/09/2013, at 8:31 PM, Kyle Sluder wrote: > > > Is this even necessary? The save panel's values should be correct at > > time of dismissal. > > > But fields in my accessory view might not be. That's the problem I'm > trying to solve - I've entered a value in a text field but have done > nothing to 'commit' the text, just hit 'Save'. So the problem is that your accessory views aren't firing their actions on panel dismissal? What happens if you ask one of your accessory controls for its -window and ask _that_ object to -makeFirstResponder:? That window should be in your own process. --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: NSSavePanel problem with sandboxing
On 5 Sep 2013, at 1:27 PM, Graham Cox wrote: > I'm using NSSavePanel in a sandboxed app. The panel includes a custom > accessory view, which works fine. > > I run the panel using -[NSSavePanel > beginSheetModalForWindow:completionHandler:]; > > In the completion handler, I call [savePanel makeFirstResponder:savePanel] so > that any text fields left in a 'pending' state commit their contents to > update the stuff they set via action methods. This is the usual way I commit > unsaved fields in any dialog or sheet, and that's always worked. > > This also works, except on 10.7 (10.6 and 10.8 seem OK). On 10.7, I get an > exception: -[NSRemoteSavePanel makeFirstResponder:]: unrecognized selector > sent to instance. The documentation for sandboxing suggests that this is > likely to be the case, though I've read somewhere that the full NSPanel > methods are available at some well-defined times (I can't however find the > documentation that mentions that, and whether the completion handler is one > of the sanctioned times). > > What can I do here to workaround this? The next thing I'd do is to see if the protocol would be of any comfort. I think it may even be preferred to resetting the window's first responder. 30 seconds' thought, take it for its worth. — F ___ 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
NSSavePanel problem with sandboxing
I'm using NSSavePanel in a sandboxed app. The panel includes a custom accessory view, which works fine. I run the panel using -[NSSavePanel beginSheetModalForWindow:completionHandler:]; In the completion handler, I call [savePanel makeFirstResponder:savePanel] so that any text fields left in a 'pending' state commit their contents to update the stuff they set via action methods. This is the usual way I commit unsaved fields in any dialog or sheet, and that's always worked. This also works, except on 10.7 (10.6 and 10.8 seem OK). On 10.7, I get an exception: -[NSRemoteSavePanel makeFirstResponder:]: unrecognized selector sent to instance. The documentation for sandboxing suggests that this is likely to be the case, though I've read somewhere that the full NSPanel methods are available at some well-defined times (I can't however find the documentation that mentions that, and whether the completion handler is one of the sanctioned times). What can I do here to workaround this? --Graham ___ 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: NSSavePanel problem with sandboxing
On 05/09/2013, at 8:31 PM, Kyle Sluder wrote: > Is this even necessary? The save panel's values should be correct at > time of dismissal. But fields in my accessory view might not be. That's the problem I'm trying to solve - I've entered a value in a text field but have done nothing to 'commit' the text, just hit 'Save'. --Graham ___ 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: NSSavePanel problem with sandboxing
On Thu, Sep 5, 2013, at 11:27 AM, Graham Cox wrote: > What can I do here to workaround this? Is this even necessary? The save panel's values should be correct at time of dismissal. --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: Dynamically change file name extension in NSSavePanel when extension is hidden
Looks like I've found a workaround:
- (IBAction)formatForTextExportChanged:(id)sender
{
self.textExportFormat = [sender indexOfSelectedItem];
NSString *path =
self.currentSavePanel.nameFieldStringValue.stringByDeletingPathExtension;
switch (self.textExportFormat) {
case 0:
path = [path stringByAppendingPathExtension:@"txt"];
self.currentSavePanel.allowedFileTypes = @[@"txt"];
break;
case 1:
path = [path stringByAppendingPathExtension:@"rtf"];
self.currentSavePanel.allowedFileTypes = @[@"rtf"];
break;
}
self.currentSavePanel.nameFieldStringValue = path;
[[NSUserDefaults standardUserDefaults] setValue:[NSNumber
numberWithInteger:self.textExportFormat]
forKey:ANTextExportFormatKey];
}
By setting the desired file type as the only allowable, the save panel now also
returns the correct file extension, even if the user chose to hide the
extension. If there is a better solution, please tell.
-António
On 10 Jul, 2013, at 10:47 , Antonio Nunes wrote:
> Hi,
>
> I show an NSSavePanel that offers the option to hide the file extension. It
> also offers the user to switch between saving .txt and .rtf formats.
>
> When the user changes the format, the following code is run:
>
> - (IBAction)formatForTextExportChanged:(id)sender
> {
>self.textExportFormat = [sender indexOfSelectedItem];
>
>NSString *path =
> self.currentSavePanel.nameFieldStringValue.stringByDeletingPathExtension;
>
>switch (self.textExportFormat) {
>case 0:
>path = [path stringByAppendingPathExtension:@"txt"];
>break;
>case 1:
>path = [path stringByAppendingPathExtension:@"rtf"];
>break;
>}
>
>self.currentSavePanel.nameFieldStringValue = path;
>
>[[NSUserDefaults standardUserDefaults] setValue:[NSNumber
> numberWithInteger:self.textExportFormat]
>
> forKey:ANTextExportFormatKey];
> }
>
> This works fine when the extension is being shown. However, when the
> extension is not shown, although the code appears to work while in the panel,
> when the panel is dismissed, the URL returned has the extension of the
> original format. How do I ensure the URL returned b the save panel ends on
> the user selected choice, even when the extension is hidden? I can't directly
> set the save panel's URL since it is read only. SInce the app is snadboxed, I
> need the save panel to return the correct URL, otherwise we later don't have
> permission to write to the URL, if I change it afterwards.
>
> -António
>
>
> There is a world of difference between
> searching for happiness and choosing
> to be happy.
>
>
>
>
>
> ___
>
> 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/devlists%40sintraworks.com
>
> This email sent to devli...@sintraworks.com
-
Perfume is the forgiveness
that the trampled flower casts
upon the heel that crushes it.
-
___
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
Dynamically change file name extension in NSSavePanel when extension is hidden
Hi,
I show an NSSavePanel that offers the option to hide the file extension. It
also offers the user to switch between saving .txt and .rtf formats.
When the user changes the format, the following code is run:
- (IBAction)formatForTextExportChanged:(id)sender
{
self.textExportFormat = [sender indexOfSelectedItem];
NSString *path =
self.currentSavePanel.nameFieldStringValue.stringByDeletingPathExtension;
switch (self.textExportFormat) {
case 0:
path = [path stringByAppendingPathExtension:@"txt"];
break;
case 1:
path = [path stringByAppendingPathExtension:@"rtf"];
break;
}
self.currentSavePanel.nameFieldStringValue = path;
[[NSUserDefaults standardUserDefaults] setValue:[NSNumber
numberWithInteger:self.textExportFormat]
forKey:ANTextExportFormatKey];
}
This works fine when the extension is being shown. However, when the extension
is not shown, although the code appears to work while in the panel, when the
panel is dismissed, the URL returned has the extension of the original format.
How do I ensure the URL returned b the save panel ends on the user selected
choice, even when the extension is hidden? I can't directly set the save
panel's URL since it is read only. SInce the app is snadboxed, I need the save
panel to return the correct URL, otherwise we later don't have permission to
write to the URL, if I change it afterwards.
-António
There is a world of difference between
searching for happiness and choosing
to be happy.
___
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: NSSavePanel problem
As you suggested Kyle, I tried to log this as a bug on bugreporter - but I couldn't log on due to a bug in the log on process. I was directed to a page to advise Apple of my difficulties I'll try again tommorrow. Thanks again Quincy. Peter On 24 Feb 2013, at 21:28, Kyle Sluder wrote: > On Feb 24, 2013, at 12:27 PM, Peter Hudson wrote: > >> I commented out the setRequiredFileType: and all is well again. >> >> As you point out, this method is deprecated. >> >> I've never come across a deprecated method that malfunctions before…... > > And it shouldn't! Please file a bug. Hopefully Apple will either fix or > remove this method. > > Great job, eagle-eyed Quincy. > > --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: NSSavePanel problem
On Feb 24, 2013, at 12:27 PM, Peter Hudson wrote: > I commented out the setRequiredFileType: and all is well again. > > As you point out, this method is deprecated. > > I've never come across a deprecated method that malfunctions before…... And it shouldn't! Please file a bug. Hopefully Apple will either fix or remove this method. Great job, eagle-eyed Quincy. --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: NSSavePanel problem
Well Quincey, your comment on the last line of code here was salient :- > NSSavePanel *sp = [NSSavePanel savePanel]; > [sp setTitle:@"Save as HTML"]; > [sp setRequiredFileType:@"html"]; I commented out the setRequiredFileType: and all is well again. As you point out, this method is deprecated. I've never come across a deprecated method that malfunctions before…... Peter ___ 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: NSSavePanel problem
It may take more effort to reproduce the problem then just building a minimal app with a NSSavePanel. I have little doubt that works as, if it did not, nearly every application out there would be crashing and they aren't. It will take effort, but you will likely need to replicate the conditions of the crash quite closely to see the same behavior. Of course, since I would assume that you cannot make your real application publicly available, perhaps you could make it available to Apple via a DTS incident. Depending on your specific circumstances, having someone at Apple sign a NDA is not unheard of. There is little doubt in my mind that your problem could be resolved quite quickly. I would recommend against degrading your user experience by auto-creating a directory on the desktop. On Feb 24, 2013, at 11:21 AM, Peter Hudson wrote: > I have built a minimal app in xCode 4.6 ( latest release ) running on 10.8.2 > - and naturally the directory popup in the NSSavePanel works perfectly. > I started the save panel, as before, with runModal. > > I have gone back to my main app and stripped the method to practically > nothing but setting the file name and doing runModal. > It still dies on me when I click the directory popup. > > I have combed my settings etc for clues. > I am compiling the app for 10.8 with a deployment platform of 10.6 > The code line started about eight years ago and with all updates of OSX and > xCode, issues have always been minimal. > It's only straight Objective-C and Cocoa API's throughout. > > Needless to say, when I run the 10.8.2 / xCode 4.6 build of the app in > 10.7 or 10.6 it runs perfectly and the directory popup runs just fine. > > I have checked it out in instruments - and there does not seem to be anything > amiss. > > Having spent ( to my horror ) nearly a 100 hours trying to run this to > ground, I have decided that our users won't get an option where to put their > files. > I'll create a directory on the desktop for them and dump any output into that > directory. > > Many thanks to all for your thoughts. > > Naturally, any more hints or suggestions welcome. > > Peter > ___ > > 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/mailist%40ericgorr.net > > This email sent to mail...@ericgorr.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: NSSavePanel problem
On Feb 24, 2013, at 09:10 , Kyle Sluder wrote:
> If that doesn't clear the problem, try launching your app with the Shift key
> held down (or turn on "Don't restore windows" in your Debug scheme's editor,
> or set the ApplePersistenceIgnoreState default to YES).
Good idea.
I'd also try using Apple menu -> "Recent Items" -> "Clear Menu".
I'd also try switching the panel mode between column view and list view, and
navigating to a series of different folder without using the popup (and
clicking Save for each one), to push older "recents" out of the popup.
> And if course, FILE A BUG! http://bugreport.apple.com. It could be that Apple
> knows about this issue already.
Yes, and attaching a crash dump might provide sufficient information to isolate
the problem.
On Feb 24, 2013, at 01:26 , Peter Hudson wrote:
> NSSavePanel *sp = [NSSavePanel savePanel];
> [sp setTitle:@"Save as HTML"];
> [sp setRequiredFileType:@"html"];
The last line of code is a bit suspect here.
'setRequiredFileType:' was deprecated in 10.6. You should be using
'setAllowedFileTypes:' instead. (If you target back to 10.5, you can use a
run-time check to decide which method to use.)
More importantly, given that the crash occurs in code that appears to be
deciding whether your app can open files with a certain extension, you could
change this last line to specify a UTI for html content ('kUTTypeHTML') rather
than an extension. UTIs are the *correct* solution.
___
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: NSSavePanel problem
On Feb 24, 2013, at 8:21 AM, Peter Hudson wrote: > > Having spent ( to my horror ) nearly a 100 hours trying to run this to > ground, I have decided that our users won't get an option where to put their > files. > I'll create a directory on the desktop for them and dump any output into that > directory. This does not sound like a good user experience, and it is incompatible with Sandboxing. Why not save a copy of your app's preferences plist, nuke the prefs, and retest your app? If that doesn't clear the problem, try launching your app with the Shift key held down (or turn on "Don't restore windows" in your Debug scheme's editor, or set the ApplePersistenceIgnoreState default to YES). Also, what items do you have in your Finder sidebar? I sounds like this problem is unavoidable, and sticking your head in the sand by avoiding a save panel here is not a workable solution. And if course, FILE A BUG! http://bugreport.apple.com. It could be that Apple knows about this issue already. --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: NSSavePanel problem
I have built a minimal app in xCode 4.6 ( latest release ) running on 10.8.2 - and naturally the directory popup in the NSSavePanel works perfectly. I started the save panel, as before, with runModal. I have gone back to my main app and stripped the method to practically nothing but setting the file name and doing runModal. It still dies on me when I click the directory popup. I have combed my settings etc for clues. I am compiling the app for 10.8 with a deployment platform of 10.6 The code line started about eight years ago and with all updates of OSX and xCode, issues have always been minimal. It's only straight Objective-C and Cocoa API's throughout. Needless to say, when I run the 10.8.2 / xCode 4.6 build of the app in 10.7 or 10.6 it runs perfectly and the directory popup runs just fine. I have checked it out in instruments - and there does not seem to be anything amiss. Having spent ( to my horror ) nearly a 100 hours trying to run this to ground, I have decided that our users won't get an option where to put their files. I'll create a directory on the desktop for them and dump any output into that directory. Many thanks to all for your thoughts. Naturally, any more hints or suggestions welcome. Peter ___ 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: NSSavePanel problem
I'll see if I can reproduce this problem in a small app.
Many thanks to everyone.
Peter
On 24 Feb 2013, at 13:35, Andy Lee wrote:
> Okay, you're calling plain old runModal, so that rules out a contextInfo
> memory management bug. And you don't set a delegate, so that rules out
> another place to look for bugs.
>
> I'm stumped. I'd repeat Eric's suggestion to reduce this to the simplest
> possible app that reproduces the problem. Also try the things Quincey
> mentioned to see if you can make the bug go away as mysteriously as it arose.
>
> --Andy
>
> On Feb 24, 2013, at 4:26 AM, Peter Hudson wrote:
>
>> Here is the code for running the NSSavePanel.
>> I run the panel using runModal.
>> I simply never return from the runModal if I click the directory popup.
>>
>> Peter
>>
>>
>>
>> -(IBAction)exportDayOutOfDaysReportToHTML:(id)sender
>> {
>>
>>
>> NSSavePanel *sp = [NSSavePanel savePanel];
>> [sp setTitle:@"Save as HTML"];
>> [sp setRequiredFileType:@"html"];
>>
>>
>>
>> SSScriptModel * model = [scriptDoc scriptModel];
>> NSString *activeStripstore = [[model stripstoreManager]
>> currentStripstoreName];
>>
>> // Go to the stripstore manager and get the list of stripstore name
>> suffixes...
>> // Only the user supplied short name ( from the stripstore name sheet ),
>> not the complete suffix with separator... e.g. "(L)"
>> NSString *stripstoreNameSuffix = @"";
>>
>> NSArray * a = [[model stripstoreManager] stripstoreNameSuffixes];
>> NSEnumerator *e = [a objectEnumerator];
>> NSString *s;
>> while( s = [e nextObject] )
>> {
>> if( [activeStripstore hasSuffix:s] )
>> {
>> stripstoreNameSuffix = [NSString stringWithString:s]; //
>> e.g. "(L)"
>> break;
>> }
>> }
>>
>>
>> NSString *suffixCoreString =
>> NSLocalizedString(@"SSStripstoreNameSuffixSeparator", nil ); // " #" at
>> the moment
>> NSString *saveFileName = [NSString stringWithFormat:@"%@ - %@%@",
>>[reportSelectorPopup
>> titleOfSelectedItem], suffixCoreString,stripstoreNameSuffix];
>>
>>
>> [sp setNameFieldStringValue:saveFileName];
>>
>>
>> int retval = [sp runModal];// I get hosed in here if I click on
>> the directory popup …..
>>
>>
>>
>> /// …..….. save names etc ...
>>
>>
>>
>>
>> }
>
___
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: NSSavePanel problem
Okay, you're calling plain old runModal, so that rules out a contextInfo memory
management bug. And you don't set a delegate, so that rules out another place
to look for bugs.
I'm stumped. I'd repeat Eric's suggestion to reduce this to the simplest
possible app that reproduces the problem. Also try the things Quincey mentioned
to see if you can make the bug go away as mysteriously as it arose.
--Andy
On Feb 24, 2013, at 4:26 AM, Peter Hudson wrote:
> Here is the code for running the NSSavePanel.
> I run the panel using runModal.
> I simply never return from the runModal if I click the directory popup.
>
> Peter
>
>
>
> -(IBAction)exportDayOutOfDaysReportToHTML:(id)sender
> {
>
>
> NSSavePanel *sp = [NSSavePanel savePanel];
> [sp setTitle:@"Save as HTML"];
> [sp setRequiredFileType:@"html"];
>
>
>
> SSScriptModel * model = [scriptDoc scriptModel];
> NSString *activeStripstore = [[model stripstoreManager]
> currentStripstoreName];
>
> // Go to the stripstore manager and get the list of stripstore name
> suffixes...
> // Only the user supplied short name ( from the stripstore name sheet ),
> not the complete suffix with separator... e.g. "(L)"
> NSString *stripstoreNameSuffix = @"";
>
> NSArray * a = [[model stripstoreManager] stripstoreNameSuffixes];
>NSEnumerator *e = [a objectEnumerator];
>NSString *s;
>while( s = [e nextObject] )
>{
>if( [activeStripstore hasSuffix:s] )
>{
>stripstoreNameSuffix = [NSString stringWithString:s]; //
> e.g. "(L)"
>break;
>}
>}
>
>
> NSString *suffixCoreString =
> NSLocalizedString(@"SSStripstoreNameSuffixSeparator", nil ); // " #" at the
> moment
> NSString *saveFileName = [NSString stringWithFormat:@"%@ - %@%@",
> [reportSelectorPopup
> titleOfSelectedItem], suffixCoreString,stripstoreNameSuffix];
>
>
> [sp setNameFieldStringValue:saveFileName];
>
>
> int retval = [sp runModal]; // I get hosed in here if I click on
> the directory popup …..
>
>
>
> /// …..….. save names etc ...
>
>
>
>
> }
___
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: NSSavePanel problem
On Feb 24, 2013, at 12:50 AM, Quincey Morris wrote: > About the only plausible way an app's code might affect something like this, > which is straightforwardly deep in NSSavePanel code, might be if there was an > accessory view doing something wrong. But even then, it seems unlikely that > merely popping up a standard menu control would crash like this. Thanks. > 2. I have actually, maybe 3-4 times since 10.8 was released, had a > non-sandboxed app crash on displaying an open/save panel, though not this > particular crash. Such crashes are repeatable until you futz around in the > panel to get past them, then they disappear without a trace. I've never found > an iota of evidence that the application code was at fault. If Peter can somehow futz around such that the crash goes away, that would be pretty good additional support for this theory. I'd suggest gathering as much data as possible first, while the bug is repeatable. Like you said, maybe it's something in prefs or in the history items that would show up in the popup if it wasn't crashing. So, save copies of the files where that info is stored. Maybe there will be a clue in the diffs of those files after the bug goes away, maybe not. I also agree with Eric Gorr that this may be a good opportunity to create a reproducible demo app which proves the problem exists. Instead of creating a new app, I'd suggest modifying this app to do nothing except open the save panel. I still don't see the objection to checking for memory errors. I can't imagine a situation where I have a mysterious, perfectly repeatable crasher and I *don't* at least rule out zombies. --Andy ___ 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: NSSavePanel problem
If you attempt to develop a sample application which reproduces the problem,
can you do so? If so, making the sample application available might be quite
useful in tracking down the problem.
On Feb 24, 2013, at 4:26 AM, Peter Hudson wrote:
> Here is the code for running the NSSavePanel.
> I run the panel using runModal.
> I simply never return from the runModal if I click the directory popup.
>
> Peter
>
>
>
> -(IBAction)exportDayOutOfDaysReportToHTML:(id)sender
> {
>
>
> NSSavePanel *sp = [NSSavePanel savePanel];
> [sp setTitle:@"Save as HTML"];
> [sp setRequiredFileType:@"html"];
>
>
>
> SSScriptModel * model = [scriptDoc scriptModel];
> NSString *activeStripstore = [[model stripstoreManager]
> currentStripstoreName];
>
>// Go to the stripstore manager and get the list of stripstore name
> suffixes...
>// Only the user supplied short name ( from the stripstore name sheet ),
> not the complete suffix with separator... e.g. "(L)"
> NSString *stripstoreNameSuffix = @"";
>
> NSArray * a = [[model stripstoreManager] stripstoreNameSuffixes];
>NSEnumerator *e = [a objectEnumerator];
>NSString *s;
>while( s = [e nextObject] )
>{
>if( [activeStripstore hasSuffix:s] )
>{
>stripstoreNameSuffix = [NSString stringWithString:s]; //
> e.g. "(L)"
>break;
>}
>}
>
>
> NSString *suffixCoreString =
> NSLocalizedString(@"SSStripstoreNameSuffixSeparator", nil ); // " #" at the
> moment
> NSString *saveFileName = [NSString stringWithFormat:@"%@ - %@%@",
> [reportSelectorPopup
> titleOfSelectedItem], suffixCoreString,stripstoreNameSuffix];
>
>
> [sp setNameFieldStringValue:saveFileName];
>
>
> int retval = [sp runModal]; // I get hosed in here if I click on
> the directory popup …..
>
>
>
> /// …..….. save names etc ...
>
>
>
>
> }
> ___
>
> 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/mailist%40ericgorr.net
>
> This email sent to mail...@ericgorr.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: NSSavePanel problem
Here is the code for running the NSSavePanel.
I run the panel using runModal.
I simply never return from the runModal if I click the directory popup.
Peter
-(IBAction)exportDayOutOfDaysReportToHTML:(id)sender
{
NSSavePanel *sp = [NSSavePanel savePanel];
[sp setTitle:@"Save as HTML"];
[sp setRequiredFileType:@"html"];
SSScriptModel * model = [scriptDoc scriptModel];
NSString *activeStripstore = [[model stripstoreManager]
currentStripstoreName];
// Go to the stripstore manager and get the list of stripstore name
suffixes...
// Only the user supplied short name ( from the stripstore name sheet ),
not the complete suffix with separator... e.g. "(L)"
NSString *stripstoreNameSuffix = @"";
NSArray * a = [[model stripstoreManager] stripstoreNameSuffixes];
NSEnumerator *e = [a objectEnumerator];
NSString *s;
while( s = [e nextObject] )
{
if( [activeStripstore hasSuffix:s] )
{
stripstoreNameSuffix = [NSString stringWithString:s]; //
e.g. "(L)"
break;
}
}
NSString *suffixCoreString =
NSLocalizedString(@"SSStripstoreNameSuffixSeparator", nil ); // " #" at the
moment
NSString *saveFileName = [NSString stringWithFormat:@"%@ - %@%@",
[reportSelectorPopup
titleOfSelectedItem], suffixCoreString,stripstoreNameSuffix];
[sp setNameFieldStringValue:saveFileName];
int retval = [sp runModal]; // I get hosed in here if I click on
the directory popup …..
/// …..….. save names etc ...
}
___
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: NSSavePanel problem
On Feb 23, 2013, at 20:46 , Jon Gary wrote: > Just because a crash happens in an apple framework doesn't mean it's note our > bug. If you can't take the time to run the code with zombies on, it's a > waste of everyone else's time guessing what's going on. Sure, I wasn't intending to suggest this would be useless. Rather, I was trying to suggest that a good place to start is with whatever can be gleaned from the evidence. On Feb 23, 2013, at 19:44 , Andy Lee wrote: > Ah, right. I'm puzzled by the question then. I suspect it was just a misunderstanding. > Can you say more about this? I thought it was possible for a memory error -- > especially a dangling pointer -- to have a delayed effect such that there's > no telling when it will cause a crash. Is there something about these > particular symptoms and this stack trace, besides the fact that it happens in > Apple's code, that rules out (or makes very unlikely) an error in Peter's > code? Perhaps the fact that it's so repeatable? I guess I was saying two independent things: 1. The backtrace doesn't really look like a memory management error in developer code, which we see quite a lot of on this list. It's very cleanly in Apple's code. Looking at the method/function names in BT lines 1-3, it appears to be trying to find out whether a certain file can be opened by the calling app, and I'd guess it's setting up to call something in Launch Services. Given that it's in a popup in a save panel, it seems a bit implausible to me that this is going to depend on an object owned by the app itself, though of course that's possible. If we wanted to go further out on a limb to speculate, it's worth noting that the crash was in an autorelease, but that doesn't help much. The invalid address (according to "VM Regions Near…", which I've never actually seen before, I think), isn't *in* an allocated VM region, which suggests it's random garbage, not a pointer to a freed object, but of course that's possible too. About the only plausible way an app's code might affect something like this, which is straightforwardly deep in NSSavePanel code, might be if there was an accessory view doing something wrong. But even then, it seems unlikely that merely popping up a standard menu control would crash like this. 2. I have actually, maybe 3-4 times since 10.8 was released, had a non-sandboxed app crash on displaying an open/save panel, though not this particular crash. Such crashes are repeatable until you futz around in the panel to get past them, then they disappear without a trace. I've never found an iota of evidence that the application code was at fault. So perhaps my history prejudices me towards blaming the NSSavePanel code. ___ 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: NSSavePanel problem
Just because a crash happens in an apple framework doesn't mean it's note our bug. If you can't take the time to run the code with zombies on, it's a waste of everyone else's time guessing what's going on. -- Jon On Feb 23, 2013, at 9:57 PM, Quincey Morris wrote: > On Feb 23, 2013, at 18:12 , Andy Lee wrote: > >> Also, to repeat part of Graham's question: is the window you're attaching >> the sheet to a floating window or a regular window? Maybe the sandboxing is >> irrelevant. >> >>> How do you run it as a panel standalone - as opposed to as a sheet ? >> >> I don't remember the method name offhand, but you'll find it if you look at >> the docs for NSSavePanel. If you try it and the crash goes away, please let >> us know -- I'm curious. > > Peter didn't run it as a sheet. You can see in line 30 of the backtrace that > his app invoked -[NSSavePanel runModal]. > > Also, according to the backtrace, the crash occurred in Cocoa frameworks > (well, Apple frameworks, since it's in C++ code), so I wouldn't hare off > looking for app memory management errors without any evidence supporting the > idea. > > Rather, I think Graham's closer to being on the correct track. I've noticed > that 10.8 NSSavePanel does have a tendency to explode, for reasons that are > unclear. When it does that, it continues to explode until you find a way of > getting it past the triggering condition. After that, it behaves properly > until the next time. > > My guess is that 10.8 re-architected NSSavePanel (to better support > sandboxing, but affecting non-sandboxing too) in such a way that there is > persistent state stored outside the application. For that reason, quitting > the app doesn't necessarily clear the problem. > > My guess is that in Peter's case the popup contains an entry that is no > longer valid. It's possible that clicking the Save button without popping up > the menu will clear it, or perhaps using the Save panel of a different > application, or rebooting. Or possibly there's a preferences file that could > be deleted. > > That's all speculation, but given the backtrace there's really no evidence > the crash is Peter's fault. > > ___ > > 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/jon%40ambrosiasw.com > > This email sent to j...@ambrosiasw.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: NSSavePanel problem
On Feb 23, 2013, at 9:57 PM, Quincey Morris wrote: > On Feb 23, 2013, at 18:12 , Andy Lee wrote: > >> Also, to repeat part of Graham's question: is the window you're attaching >> the sheet to a floating window or a regular window? Maybe the sandboxing is >> irrelevant. >> >>> How do you run it as a panel standalone - as opposed to as a sheet ? >> >> I don't remember the method name offhand, but you'll find it if you look at >> the docs for NSSavePanel. If you try it and the crash goes away, please let >> us know -- I'm curious. > > Peter didn't run it as a sheet. You can see in line 30 of the backtrace that > his app invoked -[NSSavePanel runModal]. Ah, right. I'm puzzled by the question then. > Also, according to the backtrace, the crash occurred in Cocoa frameworks > (well, Apple frameworks, since it's in C++ code), so I wouldn't hare off > looking for app memory management errors without any evidence supporting the > idea. Can you say more about this? I thought it was possible for a memory error -- especially a dangling pointer -- to have a delayed effect such that there's no telling when it will cause a crash. Is there something about these particular symptoms and this stack trace, besides the fact that it happens in Apple's code, that rules out (or makes very unlikely) an error in Peter's code? Perhaps the fact that it's so repeatable? > Rather, I think Graham's closer to being on the correct track. I've noticed > that 10.8 NSSavePanel does have a tendency to explode, for reasons that are > unclear. When it does that, it continues to explode until you find a way of > getting it past the triggering condition. After that, it behaves properly > until the next time. > > My guess is that 10.8 re-architected NSSavePanel (to better support > sandboxing, but affecting non-sandboxing too) in such a way that there is > persistent state stored outside the application. For that reason, quitting > the app doesn't necessarily clear the problem. > > My guess is that in Peter's case the popup contains an entry that is no > longer valid. It's possible that clicking the Save button without popping up > the menu will clear it, or perhaps using the Save panel of a different > application, or rebooting. Or possibly there's a preferences file that could > be deleted. > > That's all speculation, But plausible. > but given the backtrace there's really no evidence the crash is Peter's fault. This falls a little short of saying it's definitely not caused by a bug in Peter's code, so I'd like to be clear: is that what you're saying, and if so, can you explain a bit more? --Andy ___ 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: NSSavePanel problem
On Feb 23, 2013, at 18:12 , Andy Lee wrote: > Also, to repeat part of Graham's question: is the window you're attaching the > sheet to a floating window or a regular window? Maybe the sandboxing is > irrelevant. > >> How do you run it as a panel standalone - as opposed to as a sheet ? > > I don't remember the method name offhand, but you'll find it if you look at > the docs for NSSavePanel. If you try it and the crash goes away, please let > us know -- I'm curious. Peter didn't run it as a sheet. You can see in line 30 of the backtrace that his app invoked -[NSSavePanel runModal]. Also, according to the backtrace, the crash occurred in Cocoa frameworks (well, Apple frameworks, since it's in C++ code), so I wouldn't hare off looking for app memory management errors without any evidence supporting the idea. Rather, I think Graham's closer to being on the correct track. I've noticed that 10.8 NSSavePanel does have a tendency to explode, for reasons that are unclear. When it does that, it continues to explode until you find a way of getting it past the triggering condition. After that, it behaves properly until the next time. My guess is that 10.8 re-architected NSSavePanel (to better support sandboxing, but affecting non-sandboxing too) in such a way that there is persistent state stored outside the application. For that reason, quitting the app doesn't necessarily clear the problem. My guess is that in Peter's case the popup contains an entry that is no longer valid. It's possible that clicking the Save button without popping up the menu will clear it, or perhaps using the Save panel of a different application, or rebooting. Or possibly there's a preferences file that could be deleted. That's all speculation, but given the backtrace there's really no evidence the crash is Peter's fault. ___ 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: NSSavePanel problem
On Feb 23, 2013, at 7:40 PM, Peter Hudson wrote: > I wondered if it's possible to run the save panel without the row of widgets > which the directory picker popup is in ? > I couldn't find an API to remove it though. It might be possible, but I doubt it -- those controls seem an integral part of the save/open panels. To repeat Jon's question: are you familiar with using zombies to track down memory bugs? This sounds like a memory bug, and if it's in your code and if it's possible to track it down then it's worth doing so. Are you using ARC or manual retain/release? How about posting the code you use to open the save panel? Kind of a long shot but there *might* be a clue. Also, to repeat part of Graham's question: is the window you're attaching the sheet to a floating window or a regular window? Maybe the sandboxing is irrelevant. > How do you run it as a panel standalone - as opposed to as a sheet ? I don't remember the method name offhand, but you'll find it if you look at the docs for NSSavePanel. If you try it and the crash goes away, please let us know -- I'm curious. --Andy > > Peter > > > > On 24 Feb 2013, at 00:35, Graham Cox wrote: > >> >> On 24/02/2013, at 10:49 AM, Peter Hudson wrote: >> >>> Here is a truncated crash log - whole log exceeds dev-list max size; >> >> >> I have seen something similar when running the save panel as a sheet >> attached to a floating window with sandboxing does that sound like your >> situation? >> >> I fixed it temporarily by running the panel standalone not as a sheet, but I >> never got to the bottom of it. As it was part of a raft of bugs with >> sandboxing I reported it, and assumed it would gradually get fixed in a >> system release. Still waiting though. >> >> --Graham >> >> > > ___ > > 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/aglee%40mac.com > > This email sent to ag...@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
Re: NSSavePanel problem
On Feb 23, 2013, at 18:43, "Peter Hudson" wrote: > I'm not using sandboxing - the app only runs on OSX. > > I wondered if it's possible to run the save panel without the row of widgets > which the directory picker popup is in ? >From the look of that crash log, it looks like something could be wrong with >your object being autoreleased while it's still in use, like maybe the save >dlog is causing the pool to be emptied? Dunno. Just sayin' you should pay >attention the what you see in the log. Steve via iPad ___ 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: NSSavePanel problem
I'm not using sandboxing - the app only runs on OSX. I wondered if it's possible to run the save panel without the row of widgets which the directory picker popup is in ? I couldn't find an API to remove it though. How do you run it as a panel standalone - as opposed to as a sheet ? Peter On 24 Feb 2013, at 00:35, Graham Cox wrote: > > On 24/02/2013, at 10:49 AM, Peter Hudson wrote: > >> Here is a truncated crash log - whole log exceeds dev-list max size; > > > I have seen something similar when running the save panel as a sheet attached > to a floating window with sandboxing does that sound like your situation? > > I fixed it temporarily by running the panel standalone not as a sheet, but I > never got to the bottom of it. As it was part of a raft of bugs with > sandboxing I reported it, and assumed it would gradually get fixed in a > system release. Still waiting though. > > --Graham > > ___ 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: NSSavePanel problem
On 24/02/2013, at 10:49 AM, Peter Hudson wrote: > Here is a truncated crash log - whole log exceeds dev-list max size; I have seen something similar when running the save panel as a sheet attached to a floating window with sandboxing does that sound like your situation? I fixed it temporarily by running the panel standalone not as a sheet, but I never got to the bottom of it. As it was part of a raft of bugs with sandboxing I reported it, and assumed it would gradually get fixed in a system release. Still waiting though. --Graham ___ 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: NSSavePanel problem
Hi Jon Here is a truncated crash log - whole log exceeds dev-list max size; Process: WattWenn [215] Path:/Users/USER/Desktop/*/WattWenn.app/Contents/MacOS/WattWenn Identifier: WattWenn Version: V 3.1 Beta [ 0344-20120504 UI Change ] (???) Code Type: X86 (Native) Parent Process: launchd [139] User ID: 501 Date/Time: 2013-02-23 23:40:23.809 + OS Version: Mac OS X 10.8.2 (12C60) Report Version: 10 Interval Since Last Report: 53370 sec Crashes Since Last Report: 3 Per-App Crashes Since Last Report: 2 Anonymous UUID: BE71A990-9F52-5448-B908-5B6080B74C19 Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x5d08c4a3 VM Regions Near 0x5d08c4a3: MALLOC_TINY0f60-0f70 [ 1024K] rw-/rwx SM=PRV --> __TEXT 8fe61000-8fe94000 [ 204K] r-x/rwx SM=COW /usr/lib/dyld Application Specific Information: objc_msgSend() selector name: autorelease Performing @selector(exportDayOutOfDaysReportToHTML:) from sender NSButton 0x10cff70 Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libobjc.A.dylib 0x91238a87 objc_msgSend + 23 1 com.apple.FinderKit 0x96c2ff7c ApplicationURL(TString const&) + 114 2 com.apple.FinderKit 0x96c301f0 AppBundleIDCanOpenExtension(TString const&, TString const&) + 437 3 com.apple.FinderKit 0x96c309ad ThisAppCanOpenExtension(TString const&) + 232 4 com.apple.FinderKit 0x96c30e08 -[FIFinderViewGutsController finderLocationPopUpWillDisplay:] + 199 5 com.apple.FinderKit 0x96c5d99b -[FILocationPopUp adjustLocationPopUpConfiguration] + 77 6 com.apple.FinderKit 0x96c5d9cf -[FILocationPopUp menuNeedsUpdate:] + 45 7 com.apple.AppKit0x92a20c0f -[NSMenu _populateFromDelegateWithEventRef:] + 308 8 com.apple.AppKit0x929c2c76 -[NSMenu _populateWithEventRef:] + 100 9 com.apple.AppKit0x92a1fc4d -[NSCarbonMenuImpl _carbonPopulateEvent:handlerCallRef:] + 447 10 com.apple.AppKit0x92a1f7ce NSSLMMenuEventHandler + 454 11 com.apple.HIToolbox 0x98120b6b _InvokeEventHandlerUPP(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*, long (*)(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*)) + 36 12 com.apple.HIToolbox 0x97fa8594 DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 1343 13 com.apple.HIToolbox 0x97fa7980 SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) + 430 14 com.apple.HIToolbox 0x97fa77ca SendEventToEventTargetWithOptions + 94 15 com.apple.HIToolbox 0x981623b4 SendMenuPopulate(MenuData*, OpaqueEventTargetRef*, unsigned long, double, unsigned long, OpaqueEventRef*, unsigned char*) + 370 16 com.apple.HIToolbox 0x9816bfcc SendMenuOpening(MenuSelectData*, MenuData*, double, unsigned long, unsigned long, __CFDictionary*, unsigned char, unsigned char*) + 298 17 com.apple.HIToolbox 0x9816d78b PopUpMenuSelectCore(MenuData*, Point, double, Point, unsigned short, unsigned int, Rect const*, unsigned short, unsigned long, Rect const*, Rect const*, __CFString const*, OpaqueMenuRef**, unsigned short*) + 915 18 com.apple.HIToolbox 0x9816d392 _HandlePopUpMenuSelection7 + 686 19 com.apple.AppKit0x92aaf335 _NSSLMPopUpCarbonMenu3 + 4284 20 com.apple.AppKit0x92e7c129 _NSPopUpCarbonMenu3 + 107 21 com.apple.AppKit0x92aae176 -[NSCarbonMenuImpl popUpMenu:atLocation:width:forView:withSelectedItem:withFont:withFlags:withOptions:] + 407 22 com.apple.AppKit0x92cb18c2 -[NSPopUpButtonCell trackMouse:inRect:ofView:untilMouseUp:] + 625 23 com.apple.AppKit0x928e7db9 -[NSControl mouseDown:] + 867 24 com.apple.AppKit0x928dfa21 -[NSWindow sendEvent:] + 6968 25 com.apple.AppKit0x928daa0f -[NSApplication sendEvent:] + 4278 26 com.apple.AppKit0x92a50e09 -[NSApplication _modalSession:sendEvent:] + 552 27 com.apple.AppKit0x92a51173 -[NSApplication _realDoModalLoop:peek:] + 334 28 com.apple.AppKit0x92a51404 -[NSApplication _doModalLoop:peek:] + 67 29 com.apple.AppKit0x92a515c5 -[NSApplication runModalForWindow:] + 198 30 com.apple.AppKit 0x92cea55f -[NSSavePanel runModal] + 389 31 WattWenn0x0011d5c4 -[SSDayOutOfDaysSetupPanel(EXPORT_SUPPORT) exportDayOutOfDaysReportToHTML:] + 692 (SSDayOutOfDaysSetupPanel.m:1250)
Re: NSSavePanel problem
Post a crash log? Did you run with zombies on? -- Jon On Feb 23, 2013, at 6:14 PM, Peter Hudson wrote: > Hi All > > I use an NSSavePanel to save data to file in HTML format. > This panel is run from a button in one of the panels in the app. > > The whole mechanism has been working absolutely fine for a long time - up > until 10.8. > I know find that if I click in the "select directory popup" that the app > simply crashes. > The other view arrangement functions on either side of the popup work fine. > > Any suggestions appreciated. > > Peter > > > > ___ > > 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/jon%40ambrosiasw.com > > This email sent to j...@ambrosiasw.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
NSSavePanel problem
Hi All I use an NSSavePanel to save data to file in HTML format. This panel is run from a button in one of the panels in the app. The whole mechanism has been working absolutely fine for a long time - up until 10.8. I know find that if I click in the "select directory popup" that the app simply crashes. The other view arrangement functions on either side of the popup work fine. Any suggestions appreciated. Peter ___ 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: Using NSSavePanel to export to UTTypeFolder without a file extension.
Following up on my own question, NSSavePanel can be made to “work” under
PowerBox with a UTI that has no file extension, but it does get upset with
itself and fail an assertion when it elects to automatically turn on the "hide
extension" checkbox in response to the user changing the file type. The
exception is appended below. The default assertion handler just logs it and
everything seems to work, though I do worry that we're not getting a proper
reply to the request.
Updated source here:
https://www.dropbox.com/s/qjgnpee644c5eo3/NSSavePanel-kUTTypeFolder.zip
I'll be filing a radar if bugreporter comes back up.
Highlighted changes since I last posted:
- I had neglected to set a code signing identity, so the example wasn't
actually sandboxed before.
- added the com.apple.security.files.user-selected.read-write entitlement
- declared exportable formats as NSExportableTypes using real UTIs rather
than the old school NSExportableAs wherein I was using CFBundleTypeMIMETypes
completely wrong anyway.
Here is the assertion that fails. Should you wish to download and build the
project the steps to reproduce the assertion are as follows:
- in Finder preferences, turn off "Show all filename extensions"
- build and run the project
- File -> Export…,
- switch the File Format. The hide extension checkbox will turn on. Turn it
off.
- repeat the previous step as necessary. This seems to be a race condition and
may take many tries.
2013-01-23 11:21:35.728 NSSavePanel-kUTTypeFolder[26816:303] *** Assertion
failure in -[NSRemoteSavePanel connection:didReceiveRequest:],
/SourceCache/RemoteViewServices/RemoteViewServices-80.5/NSRemoteSavePanel.m:1713
2013-01-23 11:21:35.730 NSSavePanel-kUTTypeFolder[26816:303] caught exception {
name = NSInternalInconsistencyException;
reason = "window allowed unexpectedly";
} during request {requestType: 15, connections: 0, ports: 0, arguments: {
NSRemotePanelRequestKVOStateDidChangeNewStateKey = 1;
NSRemotePanelRequestKVOStateDidChangePathKey = isExtensionHidden;
}} with call stack (
0 CoreFoundation 0x7fff8a9e30a6
__exceptionPreprocess + 198
1 libobjc.A.dylib 0x7fff8baca3f0
objc_exception_throw + 43
2 CoreFoundation 0x7fff8a9e2ee8
+[NSException raise:format:arguments:] + 104
3 Foundation 0x7fff86ae96a2
-[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:]
+ 189
4 RemoteViewServices 0x7fff85bf3dc1
-[NSRemoteSavePanel connection:didReceiveRequest:] + 131
5 RemoteViewServices 0x7fff85bec73f
__block_global_4 + 68
6 CoreFoundation 0x7fff8a9a0272
__CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 18
7 CoreFoundation 0x7fff8a960a4f
__CFRunLoopDoBlocks + 255
8 CoreFoundation 0x7fff8a985220
__CFRunLoopRun + 1904
9 CoreFoundation 0x7fff8a9846b2
CFRunLoopRunSpecific + 290
10 AppKit 0x7fff860fb14b
-[NSCarbonMenuImpl performActionWithHighlightingForItemAtIndex:] + 150
11 AppKit 0x7fff85de846f -[NSMenu
_internalPerformActionForItemAtIndex:] + 36
12 AppKit 0x7fff85de82f7
-[NSCarbonMenuImpl _carbonCommandProcessEvent:handlerCallRef:] + 135
13 AppKit 0x7fff860f4245
NSSLMMenuEventHandler + 342
14 HIToolbox 0x7fff8904af0a
_ZL23DispatchEventToHandlersP14EventTargetRecP14OpaqueEventRefP14HandlerCallRec
+ 1206
15 HIToolbox 0x7fff8904a3d9
_ZL30SendEventToEventTargetInternalP14OpaqueEventRefP20OpaqueEventTargetRefP14HandlerCallRec
+ 410
16 HIToolbox 0x7fff890601bd
SendEventToEventTarget + 40
17 HIToolbox 0x7fff89096e89
_ZL18SendHICommandEventjPK9HICommandjjhPKvP20OpaqueEventTargetRefS5_PP14OpaqueEventRef
+ 443
18 HIToolbox 0x7fff8903bc11
SendMenuCommandWithContextAndModifiers + 59
19 HIToolbox 0x7fff8903bbc3
SendMenuItemSelectedEvent + 254
20 HIToolbox 0x7fff8903ba4f
_ZL19FinishMenuSelectionP13SelectionDataP10MenuResultS2_ + 94
21 HIToolbox 0x7fff891b2009
_ZL19PopUpMenuSelectCoreP8MenuData5PointdS1_tjPK4RecttjS4_S4_PK10__CFStringPP13OpaqueMenuRefPt
+ 1673
22 HIToolbox 0x7fff891b1924
_HandlePopUpMenuSelection7 + 629
23 AppKit 0x7fff8617761b
Re: Using NSSavePanel to export to UTTypeFolder without a file extension.
All good thoughts, but hold the phone. I think I have a mishmash a lot of old deprecated info plist keys and outright misapprehensions in my Info.plist, especially under CFBundleDocumentTypes and UTExportedTypeDeclarations. I think the file extension swapping will behave correctly once I've gotten it fixed. I will post an update tomorrow. I don't think your number 2 will be workable, since we're sandboxed/PowerBoxed here. If the NSSavePanel gives me a security scoped URL to a give file system path, I may not be able to write to a variant of that path. -Tom On Jan 17, 2013, at 4:57 PM, Quincey Morris wrote: > On Jan 17, 2013, at 16:20 , Thomas Bunch wrote: > >> Yes, in fact, I do exactly this. It's kind of suboptimal, in that >> NSSavePanel will first give you a warning: >> >> >> “Foo.oplx” already exists. Do you want to replace it?” and so on… the user >> will probably reflexively accept that one. >> >> Then we check and see that you're asking to dump a folder of web stuff, that >> the folder exists, that its contents don't look like a bucket of HTML and we >> pop up a second “That seems like a really bad idea, really really blow that >> away?” sheet. > > Working backwards, it seems to me you really, really want to retain this last > behavior in any situation where you're writing a folder to replace a folder. > Even if the extensions behaved the way they should, you could easily get a > situation where the user selected an entirely unrelated folder, and > "reflexively" accepted the warning about that replacement. > > If that's so, the extension behavior is somewhat a red herring. When you're > exporting multiple types via a single dialog, writing one of the types on top > of one of the other types is probably something you should always check for. > > A couple of other thoughts: > > 1. Is there any value in configuring your save panel to hide the "show/hide > extension" checkbox, and to always display extensions. That will, > incidentally, ensure that the saved item will show its extension in the > Finder, regardless of what the user normally does. You could then go ahead > and use '.htmld' without ever misleading the user that it wasn't there. > > 2. You could probably arrange to keep the "htmld" behavior in the dialog, and > rename the folder to remove the "htmld" at the end of the save. (You'd have > to use a NSDocument "perform…" method to ensure you re-set the document's > fileURL at the right time afterwards.) The drawback, of course, is that the > un-extensioned folder may already exist, and you don't know what the user > wants you to do about that. You *might* be able to mitigate that problem via > the save panel delegate's validate method. > > 3. Is there any value in the idea of exporting folders of stuff (that is, > exporting things that don't have a unique UTI) via a separate menu item that > doesn't involve choosing a type in its save panel? > ___ 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: Using NSSavePanel to export to UTTypeFolder without a file extension.
On Jan 17, 2013, at 16:20 , Thomas Bunch wrote: > Yes, in fact, I do exactly this. It's kind of suboptimal, in that NSSavePanel > will first give you a warning: > > > “Foo.oplx” already exists. Do you want to replace it?” and so on… the user > will probably reflexively accept that one. > > Then we check and see that you're asking to dump a folder of web stuff, that > the folder exists, that its contents don't look like a bucket of HTML and we > pop up a second “That seems like a really bad idea, really really blow that > away?” sheet. Working backwards, it seems to me you really, really want to retain this last behavior in any situation where you're writing a folder to replace a folder. Even if the extensions behaved the way they should, you could easily get a situation where the user selected an entirely unrelated folder, and "reflexively" accepted the warning about that replacement. If that's so, the extension behavior is somewhat a red herring. When you're exporting multiple types via a single dialog, writing one of the types on top of one of the other types is probably something you should always check for. A couple of other thoughts: 1. Is there any value in configuring your save panel to hide the "show/hide extension" checkbox, and to always display extensions. That will, incidentally, ensure that the saved item will show its extension in the Finder, regardless of what the user normally does. You could then go ahead and use '.htmld' without ever misleading the user that it wasn't there. 2. You could probably arrange to keep the "htmld" behavior in the dialog, and rename the folder to remove the "htmld" at the end of the save. (You'd have to use a NSDocument "perform…" method to ensure you re-set the document's fileURL at the right time afterwards.) The drawback, of course, is that the un-extensioned folder may already exist, and you don't know what the user wants you to do about that. You *might* be able to mitigate that problem via the save panel delegate's validate method. 3. Is there any value in the idea of exporting folders of stuff (that is, exporting things that don't have a unique UTI) via a separate menu item that doesn't involve choosing a type in its save panel? ___ 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: Using NSSavePanel to export to UTTypeFolder without a file extension.
Yes, in fact, I do exactly this. It's kind of suboptimal, in that NSSavePanel will first give you a warning: “Foo.oplx” already exists. Do you want to replace it?” and so on… the user will probably reflexively accept that one. Then we check and see that you're asking to dump a folder of web stuff, that the folder exists, that its contents don't look like a bucket of HTML and we pop up a second “That seems like a really bad idea, really really blow that away?” sheet. I think just giving this UTType a file extension is better than that experience, but having NSSavePanel properly maintain the extension (or lack thereof) would be better still. Though I could easily imagine having multiple export types whose Mime type is public.folder. -Tom On Jan 17, 2013, at 3:22 PM, Quincey Morris wrote: > On Jan 17, 2013, at 14:12 , Thomas Bunch wrote: > >> Launch, take your "document" (very much a stub), File -> Export…, "My Flat >> Format". Now File -> Export… again but this time pick "My HTML Folder >> Export". If you have your file extensions visible you'll see at this point >> that the extension is ".mff". Even so, the typical user will blow away their >> document at this point without a second thought. > > Can't you detect this situation in the save code itself? If you're actually > replacing a file with a folder, at least if file extensions were hidden when > the save panel closed, you might want to abort the save. If you're replacing > a folder with a folder … well, you'd have to decide if it's important that > the existing folder has an extension, or doesn't appear to be the kind of > folder contents you're replacing it with. > > Or, just look at the UTI for what you're replacing. If it's something your > app recognizes, you might want to avoid replacing it with a generic folder. > ___ 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: Using NSSavePanel to export to UTTypeFolder without a file extension.
On Jan 17, 2013, at 14:12 , Thomas Bunch wrote: > Launch, take your "document" (very much a stub), File -> Export…, "My Flat > Format". Now File -> Export… again but this time pick "My HTML Folder > Export". If you have your file extensions visible you'll see at this point > that the extension is ".mff". Even so, the typical user will blow away their > document at this point without a second thought. Can't you detect this situation in the save code itself? If you're actually replacing a file with a folder, at least if file extensions were hidden when the save panel closed, you might want to abort the save. If you're replacing a folder with a folder … well, you'd have to decide if it's important that the existing folder has an extension, or doesn't appear to be the kind of folder contents you're replacing it with. Or, just look at the UTI for what you're replacing. If it's something your app recognizes, you might want to avoid replacing it with a generic folder. ___ 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
Using NSSavePanel to export to UTTypeFolder without a file extension.
Hi folks, NSSavePanel does not like UTTypes with no file extension. Under PowerBox, I can't find a good workaround. One of OmniPlan's export types is a directory full of HTML and associated resources. Being an old NeXT guy, I immediately called this a .htmld file, but when the feature was debuted, the file extension was universally reviled. The most salient feedback was that real users tend to have file extensions hidden, and when they deploy this export to a web server they don't tend to realize that the file extension is part of the URL and compose their hyperlinks accordingly. People just want a directory with no file extension. I'm certain I'm not the only one who has encountered this issue, but Google is not providing anything useful. If you set things up in a way that ought to work (says I) you set yourself up for potential data-loss. When you switch file types on the NSSavePanel, the file extension is managed for you. If one of your exportable types has no file extension, it just leaves the extension from the prior selected file type. When people are exporting reports and so forth, they are quite accustomed to blowing away the previous revision of the report. In this case, the inevitable result is that they will replace their document, foo.oplx, with a directory called foo.oplx that in fact contains HTML and friends. To see this in action, download and build the following sample project: https://www.dropbox.com/s/vqun19at5efzjrc/NSSavePanel-kUTTypeFolder.zip Launch, take your "document" (very much a stub), File -> Export…, "My Flat Format". Now File -> Export… again but this time pick "My HTML Folder Export". If you have your file extensions visible you'll see at this point that the extension is ".mff". Even so, the typical user will blow away their document at this point without a second thought. Remember that we're under PowerBox here, so the URL returned by the save panel is the one we must use. There is no sanitizing it later. This might be a good time to agitate for -[NSDocument changeSaveType:] to be made public. With recent changes to NSSavePanel (especially observing its accessoryPanel's frame) this is less critical now, and in fact there is nothing you can do here to rectify the issue at hand. Did I remember to ask a question? Right… has anyone managed to get NSSavePanel to work properly with exportable types that have no extension. And if not, has a successor to the .htmld extension emerged that has traction? Thanks. -Tom ___ 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: NSSavePanel default file type
I have a save panel with a custom accessory view, but the file type popup is created by NSSavePanel If I had an offiacial way to get the NSPopUpButton I could send it a message to select the right item. Is there a way to get that button object? > > > Are you using a pre-built export dialog or a standard save dialog with a > custom accessory view? Sounds like you need to use a custom accessory view, > although this would most likely require you to code all the export features. > > Todd > > > On Jun 12, 2012, at 10:11 PM, Kurt Sutter wrote: > >> I could, if there were an official api to get that NSPopUpButton. Is there? >> I did not find one. >> >> Kurt >> >> On 12. Jun 2012, at 23:15, Martin Wierschin wrote: >> >>>> Our app allows to export its documents in a variety of formats, such as >>>> jpeg, tiff, png, pdf . Hence, we have set up the NSSavePanel to sport a >>>> file types popup that allows the user to select the desired file type. >>> ... >>>> So, how can I set the item in the popup that is initially selected when >>>> the save panel comes up? >>> >>> Can't you just call methods on the NSPopUpButton you're setting as the >>> accessory view? Ideally probably in response to -[NSDocument >>> prepareSavePanel:] >>> >>> ~Martin >>> >>> >> >> >> ___ >> >> ___ 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: NSSavePanel default file type
Are you using a pre-built export dialog or a standard save dialog with a custom accessory view? Sounds like you need to use a custom accessory view, although this would most likely require you to code all the export features. Todd On Jun 12, 2012, at 10:11 PM, Kurt Sutter wrote: > I could, if there were an official api to get that NSPopUpButton. Is there? I > did not find one. > > Kurt > > On 12. Jun 2012, at 23:15, Martin Wierschin wrote: > >>> Our app allows to export its documents in a variety of formats, such as >>> jpeg, tiff, png, pdf . Hence, we have set up the NSSavePanel to sport a >>> file types popup that allows the user to select the desired file type. >> ... >>> So, how can I set the item in the popup that is initially selected when the >>> save panel comes up? >> >> Can't you just call methods on the NSPopUpButton you're setting as the >> accessory view? Ideally probably in response to -[NSDocument >> prepareSavePanel:] >> >> ~Martin >> >> > > > ___ > > 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/applecocoalist%40filmworkers.com > > This email sent to applecocoal...@filmworkers.com > > __ > This email has been scanned by the Symantec Email Security.cloud service. > For more information please visit http://www.symanteccloud.com > __ > __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.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: NSSavePanel default file type
I could, if there were an official api to get that NSPopUpButton. Is there? I did not find one. Kurt On 12. Jun 2012, at 23:15, Martin Wierschin wrote: >> Our app allows to export its documents in a variety of formats, such as >> jpeg, tiff, png, pdf . Hence, we have set up the NSSavePanel to sport a file >> types popup that allows the user to select the desired file type. > ... >> So, how can I set the item in the popup that is initially selected when the >> save panel comes up? > > Can't you just call methods on the NSPopUpButton you're setting as the > accessory view? Ideally probably in response to -[NSDocument > prepareSavePanel:] > > ~Martin > > ___ 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: NSSavePanel default file type
> Our app allows to export its documents in a variety of formats, such as jpeg, > tiff, png, pdf . Hence, we have set up the NSSavePanel to sport a file types > popup that allows the user to select the desired file type. ... > So, how can I set the item in the popup that is initially selected when the > save panel comes up? Can't you just call methods on the NSPopUpButton you're setting as the accessory view? Ideally probably in response to -[NSDocument prepareSavePanel:] ~Martin ___ 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
NSSavePanel default file type
Hi list Our app allows to export its documents in a variety of formats, such as jpeg, tiff, png, pdf . Hence, we have set up the NSSavePanel to sport a file types popup that allows the user to select the desired file type. Now we want that save panel to remember the format of the last export operation that the user made. For example, when the user exported the last document as a pdf, the next time he selects the Export command the popup should default to the pdf format. I have found no way, however, to set the item that is selected in that popup by default. It always defaults to the first format. So, how can I set the item in the popup that is initially selected when the save panel comes up? Any advice is welcome Best regards Kurt Sutter ___ 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: NSSavePanel runModal isn't working in sandbox?
Hi Corbin + others, I wrote up my full experience including the solution I came up with on my blog here: http://www.codeotaku.com/blog/2012-06/sandboxing-core-data-and-migrations Please feel free to let me know if the code seems like a mistake. I filed a bug report Problem ID: 11544676: CoreData automatic migrations fail in sandbox. Problem ID: 11634243: NSSavePanel.URL is nil in sandbox Thanks to everyone for your help. Kind regards, Samuel On 9 June 2012 08:48, Corbin Dunn wrote: > > On Jun 8, 2012, at 11:20 AM, Samuel Williams < > space.ship.travel...@gmail.com> wrote: > > >> > >> > >> I've had no problems at all with NSSavePanel under the sandbox (the > >> inherited methods limitation that Graham mentioned excepted). > >> > >> My usage looks almost exactly like the code above except that I call > >> -beginSheetModalForWindow:completionHandler: instead of -runModal. > >> > >> BUT. You need the com.apple.security.files.user-selected.read-write > >> entitlement set to YES. > >> > >> > > Yeah, I have already set entitlements correctly. The NSPersistentDocument > > open/save are working fine. But, having issues with NSSavePanel... I > tried > > the variation with completionHandler and still had the same problem, I > also > > tried using a delegate but that also didn't seem to provide any useful > > information. > > > > Everything was working fine under a non-sandbox environment.. so its a > bit > > odd.. > > > > Maybe I could try to make a very minimal example that could be used for > > testing.. > > If you are having trouble, definitely log a bug at bugreport.apple.com > > Even if it turns out to be something you might be doing wrong, we can > update the documentation to better clarify the issue so others don't run > into it. > > thanks! > > corbin > > ___ 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: NSSavePanel runModal isn't working in sandbox?
On Jun 8, 2012, at 11:20 AM, Samuel Williams wrote: >> >> >> I've had no problems at all with NSSavePanel under the sandbox (the >> inherited methods limitation that Graham mentioned excepted). >> >> My usage looks almost exactly like the code above except that I call >> -beginSheetModalForWindow:completionHandler: instead of -runModal. >> >> BUT. You need the com.apple.security.files.user-selected.read-write >> entitlement set to YES. >> >> > Yeah, I have already set entitlements correctly. The NSPersistentDocument > open/save are working fine. But, having issues with NSSavePanel... I tried > the variation with completionHandler and still had the same problem, I also > tried using a delegate but that also didn't seem to provide any useful > information. > > Everything was working fine under a non-sandbox environment.. so its a bit > odd.. > > Maybe I could try to make a very minimal example that could be used for > testing.. If you are having trouble, definitely log a bug at bugreport.apple.com Even if it turns out to be something you might be doing wrong, we can update the documentation to better clarify the issue so others don't run into it. thanks! corbin ___ 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: NSSavePanel runModal isn't working in sandbox?
> > > I've had no problems at all with NSSavePanel under the sandbox (the > inherited methods limitation that Graham mentioned excepted). > > My usage looks almost exactly like the code above except that I call > -beginSheetModalForWindow:completionHandler: instead of -runModal. > > BUT. You need the com.apple.security.files.user-selected.read-write > entitlement set to YES. > > Yeah, I have already set entitlements correctly. The NSPersistentDocument open/save are working fine. But, having issues with NSSavePanel... I tried the variation with completionHandler and still had the same problem, I also tried using a delegate but that also didn't seem to provide any useful information. Everything was working fine under a non-sandbox environment.. so its a bit odd.. Maybe I could try to make a very minimal example that could be used for testing.. Kind regards, Samuel ___ 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: Preventing NSSavePanel from alerting file overwrite
So far, I haven¹t been able to get what I want with NSOpenPane. I will file an enhancement request. I want the user to specify the record file URL, either new or select one existing. Later, if he decides to actually record, it will simply start recording if the file does not already exist. Otherwise, I present a panel with the file path and ask if he wants to overwrite it. This is so he/she can do the prep before starting a live recording, but be reminded if a second session is about to overwrite the first (and which is displayed) , so he has a chance to apply a new file name. At record time, if the file exist, the new alert can give three choices, cancel, overwrite, or specify a new file name. In this scenario, the initial prep file selection overwrite alert is redundant, which is why I would like to eliminate it. On 6/6/12 1:12 PM, "Mike Abdullah" wrote: > Use an NSOpenPanel instead? > > On 6 Jun 2012, at 18:04, Gordon Apple wrote: > >> > Is there a way to block NSSavePanel from alerting a file overwrite? I¹m >> > using it simply to establish a URL and later alert about overwrite when a >> > record command is issued. I would prefer to not have the user see this >> > twice. >> > >> > ___ >> > >> > 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/cocoadev%40mikeabdullah.net >> > >> > This email sent to cocoa...@mikeabdullah.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: Preventing NSSavePanel from alerting file overwrite
On Jun 6, 2012, at 10:04 AM, Gordon Apple wrote: > Is there a way to block NSSavePanel from alerting a file overwrite? I¹m > using it simply to establish a URL and later alert about overwrite when a > record command is issued. I would prefer to not have the user see this > twice. No, you can't do that. You should use NSOpenPanel (as someone else mentioned). If you really want to do this, please log a feature request asking us to expose a way to do it. corbin ___ 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: Preventing NSSavePanel from alerting file overwrite
On 6 Jun 2012, at 1:03 PM, Lee Ann Rucker wrote: > Implement "panel:userEnteredFilename:confirmed:". Mine returns "nil" because > I put up my own dialog, but that also causes the panel to stay up so the user > has to enter something else. > > I haven't tried but I'd guess returning a placeholder filename that's known > not to exist will also prevent the dialog showing and let the panel close. > You can save the incoming filename so you know what the real user choice was, > or append a magic extension to mark it as a temporary placeholder for an > existing file. This is a problem for sandboxing: > Open and Save Dialog Behavior with App Sandbox > > Certain NSOpenPanel and NSSavePanel methods behave differently when App > Sandbox is enabled for your app: > > • You cannot invoke the OK button using the ok: method. > • You cannot rewrite the user’s selection using the > panel:userEnteredFilename:confirmed: method from the NSOpenSavePanelDelegate > protocol. <http://developer.apple.com/library/mac/documentation/Security/Conceptual/AppSandboxDesignGuide/AppSandboxInDepth/AppSandboxInDepth.html#//apple_ref/doc/uid/TP40011183-CH3-SW8> — F ___ 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: Preventing NSSavePanel from alerting file overwrite
Use an NSOpenPanel instead? On 6 Jun 2012, at 18:04, Gordon Apple wrote: > Is there a way to block NSSavePanel from alerting a file overwrite? I¹m > using it simply to establish a URL and later alert about overwrite when a > record command is issued. I would prefer to not have the user see this > twice. > > ___ > > 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/cocoadev%40mikeabdullah.net > > This email sent to cocoa...@mikeabdullah.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: Preventing NSSavePanel from alerting file overwrite
On Jun 6, 2012, at 10:04 AM, Gordon Apple wrote: > Is there a way to block NSSavePanel from alerting a file overwrite? I¹m > using it simply to establish a URL and later alert about overwrite when a > record command is issued. I would prefer to not have the user see this > twice. Implement "panel:userEnteredFilename:confirmed:". Mine returns "nil" because I put up my own dialog, but that also causes the panel to stay up so the user has to enter something else. I haven't tried but I'd guess returning a placeholder filename that's known not to exist will also prevent the dialog showing and let the panel close. You can save the incoming filename so you know what the real user choice was, or append a magic extension to mark it as a temporary placeholder for an existing file. ___ 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: NSSavePanel runModal isn't working in sandbox?
On Jun 6, 2012, at 13:08 , cocoa-dev-requ...@lists.apple.com wrote: > Date: Wed, 06 Jun 2012 14:50:17 +1000 > From: Graham Cox > To: Samuel Williams > Message-ID: > > Are you aware that this class is riddled with severe bugs under the current > sandbox implementation? > > The dev forums will reveal more details. > > Also, NSSavePanel doesn't inherit from NSPanel under sandboxing, so if you > are expecting to use inherited methods, they don't work. > ... > On 06/06/2012, at 1:41 PM, Samuel Williams wrote: >> >> I'm having trouble with NSSavePanel runModal in a sandbox: >> >> NSSavePanel * savePanel = [NSSavePanel savePanel]; >> savePanel.title = @"Document Migration"; >> savePanel.directoryURL = url; >> savePanel.nameFieldStringValue = [url lastPathComponent]; >> savePanel.allowedFileTypes = [NSArray arrayWithObject:typeName]; >> savePanel.message = @"Your document needs to be upgraded."; >> >> [savePanel setCanSelectHiddenExtension:YES]; >> [savePanel setExtensionHidden:YES]; >> >> NSInteger result = [savePanel runModal]; I've had no problems at all with NSSavePanel under the sandbox (the inherited methods limitation that Graham mentioned excepted). My usage looks almost exactly like the code above except that I call -beginSheetModalForWindow:completionHandler: instead of -runModal. BUT. You need the com.apple.security.files.user-selected.read-write entitlement set to YES. HTH, -- Rainer Brockerhoff Belo Horizonte, Brazil "In the affairs of others even fools are wise In their own business even sages err." Weblog: http://www.brockerhoff.net/blog ___ 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
Preventing NSSavePanel from alerting file overwrite
Is there a way to block NSSavePanel from alerting a file overwrite? I¹m using it simply to establish a URL and later alert about overwrite when a record command is issued. I would prefer to not have the user see this twice. ___ 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: NSSavePanel runModal isn't working in sandbox?
What entitlements do you have?
On 6 Jun 2012, at 04:41, Samuel Williams wrote:
> Hi,
>
> I'm having trouble with NSSavePanel runModal in a sandbox:
>
> NSSavePanel * savePanel = [NSSavePanel savePanel];
> savePanel.title = @"Document Migration";
> savePanel.directoryURL = url;
> savePanel.nameFieldStringValue = [url lastPathComponent];
> savePanel.allowedFileTypes = [NSArray arrayWithObject:typeName];
> savePanel.message = @"Your document needs to be upgraded.";
>
> [savePanel setCanSelectHiddenExtension:YES];
> [savePanel setExtensionHidden:YES];
>
> NSInteger result = [savePanel runModal];
>
> if (result == NSFileHandlingPanelOKButton) {
> NSAssert(savePanel.URL != nil, @"NSSavePanel returned nil for URL");
>
>
> Without the sandbox, it works fine, with the sandbox, the savePanel.URL is
> nil.
>
> Any ideas what is going on? I looked at the documentation on sandbox and it
> didn't mention anything about runModal. I'm going to try using the
> completion handler method...
>
> Kind regards,
> Samuel
> ___
>
> 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/cocoadev%40mikeabdullah.net
>
> This email sent to cocoa...@mikeabdullah.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: NSSavePanel runModal isn't working in sandbox?
On 06/06/2012, at 2:55 PM, Samuel Williams wrote: > Hi Graham, > > What dev forums are you talking about? > If you are a registered apple developer, there are a number of forms at developer.apple.com, including one for sandboxing issues. > The fact is that the documentation on Apple's site doesn't mention any > existing issues so it is very frustrating to have spent several days banging > my head against these issues wondering if it is something to do with my code > or not... Thanks for clarifying the situation. No, they seem to like to pretend it's all working just fine in the documentation. However, Apple engineers contributing to the forums are more candid. The current documentation does talk about the differences with NSSavePanel, or at least how it's supposed to work: https://developer.apple.com/library/mac/#documentation/Security/Conceptual/AppSandboxDesignGuide/AppSandboxInDepth/AppSandboxInDepth.html#//apple_ref/doc/uid/TP40011183-CH3-SW4 --Graham ___ 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: NSSavePanel runModal isn't working in sandbox?
Hi Graham,
What dev forums are you talking about?
NSSavePanel seems completely unusable.
Even the simplest example isn't working for me:
- (void) finishLaunching {
[super finishLaunching];
NSSavePanel * savePanel = [NSSavePanel savePanel];
[savePanel runModal];
NSLog(@"End model session for savePanel: %@", savePanel.URL);
}
That gives nil as a result.
The fact is that the documentation on Apple's site doesn't mention any
existing issues so it is very frustrating to have spent several days
banging my head against these issues wondering if it is something to do
with my code or not... Thanks for clarifying the situation.
Kind regards,
Samuel
On 6 June 2012 16:50, Graham Cox wrote:
> Are you aware that this class is riddled with severe bugs under the
> current sandbox implementation?
>
> The dev forums will reveal more details.
>
> Also, NSSavePanel doesn't inherit from NSPanel under sandboxing, so if you
> are expecting to use inherited methods, they don't work.
>
> File bugs - we can't adopt sandboxing until these issues are properly
> fixed.
>
>
> --Graham
>
>
>
>
>
> On 06/06/2012, at 1:41 PM, Samuel Williams wrote:
>
> > Hi,
> >
> > I'm having trouble with NSSavePanel runModal in a sandbox:
> >
> > NSSavePanel * savePanel = [NSSavePanel savePanel];
> > savePanel.title = @"Document Migration";
> > savePanel.directoryURL = url;
> > savePanel.nameFieldStringValue = [url lastPathComponent];
> > savePanel.allowedFileTypes = [NSArray arrayWithObject:typeName];
> > savePanel.message = @"Your document needs to be upgraded.";
> >
> > [savePanel setCanSelectHiddenExtension:YES];
> > [savePanel setExtensionHidden:YES];
> >
> > NSInteger result = [savePanel runModal];
> >
> > if (result == NSFileHandlingPanelOKButton) {
> > NSAssert(savePanel.URL != nil, @"NSSavePanel returned nil for URL");
> >
> >
> > Without the sandbox, it works fine, with the sandbox, the savePanel.URL
> is
> > nil.
> >
> > Any ideas what is going on? I looked at the documentation on sandbox and
> it
> > didn't mention anything about runModal. I'm going to try using the
> > completion handler method...
>
>
___
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: NSSavePanel runModal isn't working in sandbox?
Are you aware that this class is riddled with severe bugs under the current
sandbox implementation?
The dev forums will reveal more details.
Also, NSSavePanel doesn't inherit from NSPanel under sandboxing, so if you are
expecting to use inherited methods, they don't work.
File bugs - we can't adopt sandboxing until these issues are properly fixed.
--Graham
On 06/06/2012, at 1:41 PM, Samuel Williams wrote:
> Hi,
>
> I'm having trouble with NSSavePanel runModal in a sandbox:
>
> NSSavePanel * savePanel = [NSSavePanel savePanel];
> savePanel.title = @"Document Migration";
> savePanel.directoryURL = url;
> savePanel.nameFieldStringValue = [url lastPathComponent];
> savePanel.allowedFileTypes = [NSArray arrayWithObject:typeName];
> savePanel.message = @"Your document needs to be upgraded.";
>
> [savePanel setCanSelectHiddenExtension:YES];
> [savePanel setExtensionHidden:YES];
>
> NSInteger result = [savePanel runModal];
>
> if (result == NSFileHandlingPanelOKButton) {
> NSAssert(savePanel.URL != nil, @"NSSavePanel returned nil for URL");
>
>
> Without the sandbox, it works fine, with the sandbox, the savePanel.URL is
> nil.
>
> Any ideas what is going on? I looked at the documentation on sandbox and it
> didn't mention anything about runModal. I'm going to try using the
> completion handler method...
___
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
NSSavePanel runModal isn't working in sandbox?
Hi,
I'm having trouble with NSSavePanel runModal in a sandbox:
NSSavePanel * savePanel = [NSSavePanel savePanel];
savePanel.title = @"Document Migration";
savePanel.directoryURL = url;
savePanel.nameFieldStringValue = [url lastPathComponent];
savePanel.allowedFileTypes = [NSArray arrayWithObject:typeName];
savePanel.message = @"Your document needs to be upgraded.";
[savePanel setCanSelectHiddenExtension:YES];
[savePanel setExtensionHidden:YES];
NSInteger result = [savePanel runModal];
if (result == NSFileHandlingPanelOKButton) {
NSAssert(savePanel.URL != nil, @"NSSavePanel returned nil for URL");
Without the sandbox, it works fine, with the sandbox, the savePanel.URL is
nil.
Any ideas what is going on? I looked at the documentation on sandbox and it
didn't mention anything about runModal. I'm going to try using the
completion handler method...
Kind regards,
Samuel
___
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: NSSavePanel: Another sandbox issue
On May 31, 2012, at 5:46 PM, Kyle Sluder wrote:
>
> On May 31, 2012, at 2:43 PM, Alex Zavatone wrote:
>
>>
>> So, before I start waving my hands in the air, running around the office and
>> panicking, does this mean that the user can not save files where ever he/she
>> wants to on the HD in future versions of the Mac OS?
>
> No, it's completely and totally incorrect. It's obvious Marco either didn't
> read or didn't understand the Sandboxing Guide.
>
> --Kyle Sluder
OK Kyle, I've watched the WWDC 2011 Session 203 - "Introducing the App Sandbox"
video and read:
http://developer.apple.com/library/ios/#DOCUMENTATION/Miscellaneous/Reference/EntitlementKeyReference/EnablingAppSandbox/EnablingAppSandbox.html
Table 3-2 in the above link states that your app can be configured to save to
files and folders the user opens.
It also states that programmatic access (Table 3-3) can be enabled for
Downloads, Music, Movies and Pictures. (Why not Documents?)
So, it looks like you can set up an app to save into known places and also to
let the user select where he/she opens/saves files in the file system. (Table
3-2 again).
Now, I've got no experience with this. I'm just trying to interpret the docs,
so as I typed, it looks like this will be possible and not be a VIsta style
permissions nightmare.
I'm assuming you can still save app prefs in the ~/Library/Preferences/ folder,
but your app can't save elsewhere, like to root, without a user directed action.
>From 31:36 in the WWDV Session 203 video:
HOME = ~/Library/Containers/App/
CFFIXED_USER_HOME = ~/Library/Containers/App/
NSHomeDirectory() will return HOME (as defined above) and if you try to
open("/Users/krsric/Library/foo") an action like this will be denied.
I'm assuming that from the user's experience, the implications will (hopefully)
be minimal.
I wonder what would happen if the user quits the sandbox deamon, or if we, as
users, will still have access to apps like Application Monitor, or have shell
access in sandboxed applications.
Admittedly, I don't have close to a grip around all of the potential
implications sandboxing imposes, and what it may not affect.
I do really recommend checking out the Entitlements reference and watching the
video from 31:36 on. Log in to developer.apple.com and get that video.
Cheers,
- Alex
___
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: NSSavePanel: Another sandbox issue
On May 31, 2012, at 2:46 PM, Kyle Sluder wrote: > On May 31, 2012, at 2:43 PM, Alex Zavatone wrote: > >> >> So, before I start waving my hands in the air, running around the office and >> panicking, does this mean that the user can not save files where ever he/she >> wants to on the HD in future versions of the Mac OS? > > No, it's completely and totally incorrect. It's obvious Marco either didn't > read or didn't understand the Sandboxing Guide. Read... but forgot. And Kyle is also correct that I don't fully understand the Sandboxing Guide. It doesn't help that every time I read it there is a new version. The problem I was replying to was an attempt to save something *inside* the sandbox container and had nothing to do with the Documents folder. I mis-thought and mis-wrote as a result. I'll shut up now. Marc ___ 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: NSSavePanel: Another sandbox issue
On May 31, 2012, at 5:46 PM, Kyle Sluder wrote: > > On May 31, 2012, at 2:43 PM, Alex Zavatone wrote: > >> >> So, before I start waving my hands in the air, running around the office and >> panicking, does this mean that the user can not save files where ever he/she >> wants to on the HD in future versions of the Mac OS? > > No, it's completely and totally incorrect. It's obvious Marco either didn't > read or didn't understand the Sandboxing Guide. OK, I'll watch the WWDC video on it and try to summarize to hopefully ward off some FUD. Thanks ___ 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: NSSavePanel: Another sandbox issue
On May 31, 2012, at 2:43 PM, Alex Zavatone wrote: > > So, before I start waving my hands in the air, running around the office and > panicking, does this mean that the user can not save files where ever he/she > wants to on the HD in future versions of the Mac OS? No, it's completely and totally incorrect. It's obvious Marco either didn't read or didn't understand the Sandboxing Guide. --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: NSSavePanel: Another sandbox issue
On May 30, 2012, at 10:54 PM, Marco S Hyman wrote: >> 3. When I use -setDirectoryURL: and the URL is somewhere in my sandbox, the >> actual URL displayed is the old location, back in ~/Library/Application >> Support (!) > > When using a sandbox in Mac OS X 10.7 and later, the home directory is the > app’s container directory. That is > > ~ ==> /Users//Library/Containers//Data/ > > Now the fact that the application is sandboxed and lives in a container > is irrelevant to the user. Try taking off your developer hat and > putting on your dumb user hat. A user will want to save somewhere, > perhaps in his Documents directory. In a sandboxed app that will be > /Users//Library/Containers//Data/Documents/ So, before I start waving my hands in the air, running around the office and panicking, does this mean that the user can not save files where ever he/she wants to on the HD in future versions of the Mac OS? > The user doesn't know or care what the actual path is. Why are you > trying to show it in a save dialog. > > Marc Sometimes, the user does. If sandboxing ALLOWS the user to save in a private special place but PREVENTS them saving files where they choose, then this is a scary path. I certainly hope this is not the case. In all of Apple's success, I see the openness and fun to use nature of the Mac platform running away right in front of us. ___ 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: NSSavePanel: Another sandbox issue
> > P.S. Just saw this: > http://www.macworld.com.au/news/ac-devs-air-frustrations-at-mac-app-store-sandboxing-debacle-55502/ > I would say that's a pretty reasonable article about the current state of sandboxing as I understand it. I've given up for a while on the OSX thing I was writing (which uses iCloud so it has to be sandboxed) because struggling with the entitlements at the same time as struggling with OSX (I started from iOS and so OSX is still a little alien) was frustrating. I read the forums and follow quite a few threads to see how things are evolving, I'll go back to it one day. I'm sure Apple employees read the dev forums, I wish they replied a bit more, I think they could both help a lot of people who are thrashing around in the dark and get more rapidly to finding all the edge cases in the sandbox and help people to file better bug reports. It's rather hard to file good ones when you really don't have a clue how it's supposed to work in the first place. I think they could make the process of making sandbox better, or fit for purpose, a bit more collaborative and it would help everyone, themselves included. ___ 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: NSSavePanel: Another sandbox issue
On 31/05/2012, at 12:54 PM, Marco S Hyman wrote: > The user doesn't know or care what the actual path is. Why are you > trying to show it in a save dialog. I don't, as such, but the save panel shows the full path and it's simply wrong. I have a specific location inside my Application Support folder where I save templates. By saving them there, they are automatically included in the Template Browser, which is another part of my app. Because App Support is now inside the sandbox, that's where it needs to go, and that's no problem. Except that when I try to set this directory, the save panel takes me to the OLD ~/Library/Application Support/... directory. I could save the file there, except that it's outside the sandbox, and my template browser is not looking there any more. If the save panel hid the real location from me by hiding part of the path and making it look like ~/Library/App Support, that would be fine, but it doesn't do that - it literally sets the incorrect directory outside of my sandbox. One possible reason for it might be that there is a folder in the old location for my previous version's app support - I need to check if that is the cause of the confusion. But that's not going to help our users who are upgrading from the previous (non sandboxed) version and will have those directories. The right thing for Apple to do at this point is to revoke the sandboxing requirement until 10.8. (or possibly until whatever version of 10.7.x is verified to work properly and we can have sandboxing conditional by version) Who's going to step up to the plate and make the decision? --Graham P.S. Just saw this: http://www.macworld.com.au/news/ac-devs-air-frustrations-at-mac-app-store-sandboxing-debacle-55502/ ___ 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: NSSavePanel: Another sandbox issue
On May 30, 2012, at 7:54 PM, Marco S Hyman wrote: > In a sandboxed app that will be > /Users//Library/Containers//Data/Documents/ What? No! The whole point of sandboxing and NSSavePanel is that Powerbox will poke holes into the user's *actual* Documents directory. Graham, the behavior seeing is a known bug that was reported a while ago. There's more info on the dev forums but I can't access that right now. --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: NSSavePanel: Another sandbox issue
> 3. When I use -setDirectoryURL: and the URL is somewhere in my sandbox, the > actual URL displayed is the old location, back in ~/Library/Application > Support (!) When using a sandbox in Mac OS X 10.7 and later, the home directory is the app’s container directory. That is ~ ==> /Users//Library/Containers//Data/ Now the fact that the application is sandboxed and lives in a container is irrelevant to the user. Try taking off your developer hat and putting on your dumb user hat. A user will want to save somewhere, perhaps in his Documents directory. In a sandboxed app that will be /Users//Library/Containers//Data/Documents/ The user doesn't know or care what the actual path is. Why are you trying to show it in a save dialog. Marc ___ 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: NSSavePanel: Another sandbox issue
On 31/05/2012, at 9:57 AM, Graham Cox wrote: > So, internally the panel is throwing an exception, due to a nil object. But > why? what am I doing wrong here? OK, some more discoveries. 1. The problem only occurs with a delegate set on the panel. The delegate isn't called - just its presence is enough. 2. The problem pertains only to column view. If I temporarily remove the delegate so the panel comes up, switch to list view, and put the delegate back, it's OK. 3. When I use -setDirectoryURL: and the URL is somewhere in my sandbox, the actual URL displayed is the old location, back in ~/Library/Application Support (!) 4. The save panel under sandboxing is currently a disaster, and this is a showstopper for adding sandboxing at this point. There is simply NO WAY Apple should be forcing sandboxing on developers as of tomorrow with the system in such a broken state. It's going to make them look very cavalier and arrogant indeed, and will hurt the reputation of OS X. "It Just Works"? My a**e. G. ___ 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: NSSavePanel: Another sandbox issue
> [savePanel beginSheetModalForWindow:[self windowForSheet] > completionHandler:completionHandler]; > > > Anyone else come across this issue? My understanding is that with sandboxing, > the save panel is a bit more involved since it has to open up holes in the > sandbox on behalf of the user, but in this case it's actually inside the > sandbox. More info - I just noticed that this is getting logged. 31/05/12 9:54:01.793 AM com.apple.security.pboxd: *** -[__NSArrayM insertObject:atIndex:]: object cannot be nil 31/05/12 9:54:01.793 AM com.apple.security.pboxd: 2012-05-31 09:54:01.792 com.apple.security.pboxd[15928:1707] *** -[__NSArrayM insertObject:atIndex:]: object cannot be nil 31/05/12 9:54:01.794 AM com.apple.security.pboxd: ( 0 CoreFoundation 0x7fff8983ef56 __exceptionPreprocess + 198 1 libobjc.A.dylib 0x7fff89d41d5e objc_exception_throw + 43 2 CoreFoundation 0x7fff897e5ab8 -[__NSArrayM insertObject:atIndex:] + 296 3 com.apple.security.pboxd0x00010f0eadb6 com.apple.security.pboxd + 19894 4 FinderKit 0x7fff8e2eb4e3 -[FIFinderViewGutsController browserSelectionChanged] + 93 5 FinderKit 0x7fff8e263af2 -[FI_TBrowserViewController selectionChangedByUserAction:] + 130 6 FinderKit 0x7fff8e2b4a86 -[FI_TColumnViewController selectionChangedByUserAction:] + 91 7 FinderKit 0x7fff8e2b8ac7 _ZN17StColumnOptimizerD2Ev + 153 8 FinderKit 0x7fff8e2b0a0d -[FI_TColumnViewController openTarget] + 1301 9 FinderKit 0x7fff8e2efb82 -[FIFinderViewGutsController commonFinishInitialization] + 103 10 FinderKit 0x7fff8e2ec387 -[FIFinderViewGutsController buildBrowserView:] + 167 11 FinderKit 0x7fff8e2ec84f -[FIFinderViewGutsController setTargetPath:withViewStyle:] + 635 12 FinderKit 0x7fff8e2ed21e -[FIFinderViewGutsController setViewStyle:] + 467 13 Foundation 0x7fff8de9ac46 _NSSetObjectValueAndNotify + 261 14 FinderKit 0x7fff8e2f2389 -[FIFinderView setViewStyle:] + 253 15 AppKit 0x00007fff8b389cd7 -[NSSavePanel beginWithCompletionHandler:] + 88 16 com.apple.security.pboxd0x00010f0e985f com.apple.security.pboxd + 14431 17 RemoteViewServices 0x7fff89e8d4d3 __45-[NSRemoteServiceConnection _setupConnection]_block_invoke_0141 + 69 18 CoreFoundation 0x7fff897f3dfc __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 12 19 CoreFoundation 0x7fff897abf02 __CFRunLoopDoBlocks + 322 20 CoreFoundation 0x7fff897d3fa7 __CFRunLoopRun + 2023 21 CoreFoundation 0x7fff897d3486 CFRunLoopRunSpecific + 230 22 HIToolbox 0x7fff8a0964d3 RunCurrentEventLoopInMode + 277 23 HIToolbox 0x7fff8a09d781 ReceiveNextEventCommon + 355 24 HIToolbox 0x7fff8a09d60e BlockUntilNextEventMatchingListInMode + 62 25 AppKit 0x7fff8ae52e31 _DPSNextEvent + 659 26 AppKit 0x7fff8ae52735 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 135 27 AppKit 0x7fff8ae4f071 -[NSApplication run] + 470 28 com.apple.security.pboxd0x00010f0e8a35 com.apple.security.pboxd + 10805 29 com.apple.security.pboxd0x00010f0e73e4 com.apple.security.pboxd + 5092 ) So, internally the panel is throwing an exception, due to a nil object. But why? what am I doing wrong here? --Graham ___ 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
NSSavePanel: Another sandbox issue
In my app I put up a save panel to save a file in a particular place within my ~/Library/Application Support folder. When not sandboxed, this works fine. When sandboxed, the URL that is set in the panel is correct (it's inside the sandbox now), but the save panel doesn't appear. In fact, it acts as if it's visible, but it's not, so my app enters a state that the user cannot recover it from - I have to stop it in the debugger or Force Quit. The stack trace is: #0 0x7fff85ba667a in mach_msg_trap () #1 0x7fff85ba5d71 in mach_msg () #2 0x7fff897cb50c in __CFRunLoopServiceMachPort () #3 0x7fff897d3c74 in __CFRunLoopRun () #4 0x7fff897d3486 in CFRunLoopRunSpecific () #5 0x7fff897e319f in CFRunLoopRun () #6 0x7fff89e90bdc in -[NSRemoteSavePanel beginSheetModalForWindow:completionHandler:] () #7 0x0001000a7eae in -[GCOrteliusDocument(Templates) saveCopyAsTemplateAction:] at /Users/grahamcox/Projects/Artboard/Artboard/Source/Code/GCOrteliusDocument+Templates.m:310 #8 0x7fff8982e70d in -[NSObject performSelector:withObject:] () #9 0x7fff8af55f7e in -[NSApplication sendAction:to:from:] () The code is very simple: NSSavePanel* savePanel = [NSSavePanel savePanel]; [savePanel setCanCreateDirectories:YES]; [savePanel setCanSelectHiddenExtension:NO]; [savePanel setExtensionHidden:YES]; [savePanel setDirectoryURL:[[self class] userTemplatesURL]]; // URL differs if sandboxed/not sandboxed [savePanel beginSheetModalForWindow:[self windowForSheet] completionHandler:completionHandler]; Anyone else come across this issue? My understanding is that with sandboxing, the save panel is a bit more involved since it has to open up holes in the sandbox on behalf of the user, but in this case it's actually inside the sandbox. --Graham ___ 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: Proper handling of NSSavePanel and 'Do you want to replace it?' dialog
On Sep 16, 2011, at 12:33 PM, Sean McBride wrote: > Hi all, > > NSSavePanel will automatically show the user a 'Do you want to replace' sheet > if he tries to save with an existing name. > > What the correct way to proceed when replacement is needed? > > Option 1: First delete the existing item yourself. I've read this doesn't > work when sandboxed (not sure if that's a bug or feature). > > Option 2: Append/overwrite the existing item. This works if you're writing a > flat file and replacing a flat file. But if the existing item is a > directory, writeToURL is giving me an "Error Domain=NSPOSIXErrorDomain > Code=21 "The operation couldn’t be completed. Is a directory")" > > What's the correct technique? I performed a quick test using TextEdit as my guinea pig, and noticed that when TextEdit overwrites an existing RTFD bundle, TextEdit deletes the existing bundle and creates a new one in its place. (You can see this for yourself by using the fs_usage tool.) And since TextEdit is the most "Mac-like" app I know, I believe the correct technique is option 2 & deleting the existing directory if you get that error when trying to save. Nick Zitzmann <http://www.chronosnet.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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Proper handling of NSSavePanel and 'Do you want to replace it?' dialog
Hi all, NSSavePanel will automatically show the user a 'Do you want to replace' sheet if he tries to save with an existing name. What the correct way to proceed when replacement is needed? Option 1: First delete the existing item yourself. I've read this doesn't work when sandboxed (not sure if that's a bug or feature). Option 2: Append/overwrite the existing item. This works if you're writing a flat file and replacing a flat file. But if the existing item is a directory, writeToURL is giving me an "Error Domain=NSPOSIXErrorDomain Code=21 "The operation couldn’t be completed. Is a directory")" What's the correct technique? Thanks, -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ 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
Re: NSSavePanel called from 64-bit NPAPI plugin
On 6/19/2011 10:41 PM, Kevin Peterson wrote: I'm attempting a "save as" [NSSavePanel savePanel] modal dialog from an NPAPI plugin compiled for x86_64 and running under Safari 5.0.5 on OSX 10.6.7. Whenever the call to runModal completes Safari ends up in a wedged state in which none of menu pull downs are accessible (all greyed out) and the only way to exit is to force a quit. I don't fully understand the structure of a modal window but in the wedged state it appears as though there's still a modal window open and expecting input even though it's not visible. I've read some comments on this list that suggest that that creating windows from the WebkitPluginHost process is discouraged (http://lists.apple.com/archives/cocoa-dev/2010/Jun/msg00868.html) but does this really apply to the simple Cocoa/modal dialogs like NSSavePanel and NSOpenPanel? I've reproduced this with some simple modifications to one of the WebKit example NPAPI plugins. Safari gets wedged when the call to runModal is made from a scriptable plugin method. I've done some debugging with the webkit source and this is definitely a webkit-ism so I'll re-post there. But for what it's worth, webkit creates an empty "placeholder modal window" for which the call to [NSApp stopModal] is not happening (is scheduled, but not invoked). Looks like a bug to me but I don't fully understand the root cause yet. Thanks, Kevin ___ 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
NSSavePanel called from 64-bit NPAPI plugin
I'm attempting a "save as" [NSSavePanel savePanel] modal dialog from an NPAPI plugin compiled for x86_64 and running under Safari 5.0.5 on OSX 10.6.7. Whenever the call to runModal completes Safari ends up in a wedged state in which none of menu pull downs are accessible (all greyed out) and the only way to exit is to force a quit. I don't fully understand the structure of a modal window but in the wedged state it appears as though there's still a modal window open and expecting input even though it's not visible. I've read some comments on this list that suggest that that creating windows from the WebkitPluginHost process is discouraged (http://lists.apple.com/archives/cocoa-dev/2010/Jun/msg00868.html) but does this really apply to the simple Cocoa/modal dialogs like NSSavePanel and NSOpenPanel? Thanks in advance, Kevin ___ 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
Re: NSSavePanel panel:shouldShowFilename:
On Nov 15, 2010, at 7:57 PM, Leo wrote: > From: Quincey Morris > >> a number of system extensions (like Default Folder, but I think that wasn't >> the first) added the ability to option-click on a disabled item to prefill >> the >> text field with an existing name, > >> At some point (possibly Mac OS X 10.0), Apple quietly adopted this very >> useful >> convention. > > I once submitted a request to Apple, maybe I'm in minority, but I hope this > behavior will be optional one day. Like Opt-click would be perfect. > > I worked at a major ad agency for several years, and this behavior caused > major problems, misunderstandings and loss of time. > > Most of the time, people click on the file list occasionally (maybe to > type-scroll to desired folder), the file gets "quietly" renamed, you save it > - and can never find it because it was saved under a name you never wanted > or thought about. > > I had myself to cancel the Save dialog countless times to avoid saving files > under unwanted names. Undo works to undo the change. corbin ___ 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
Re: NSSavePanel panel:shouldShowFilename:
From: Quincey Morris > a number of system extensions (like Default Folder, but I think that wasn't > the first) added the ability to option-click on a disabled item to prefill the > text field with an existing name, > At some point (possibly Mac OS X 10.0), Apple quietly adopted this very useful > convention. I once submitted a request to Apple, maybe I'm in minority, but I hope this behavior will be optional one day. Like Opt-click would be perfect. I worked at a major ad agency for several years, and this behavior caused major problems, misunderstandings and loss of time. Most of the time, people click on the file list occasionally (maybe to type-scroll to desired folder), the file gets "quietly" renamed, you save it - and can never find it because it was saved under a name you never wanted or thought about. I had myself to cancel the Save dialog countless times to avoid saving files under unwanted names. Leo ___ 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
Re: NSSavePanel panel:shouldShowFilename:
On 15 Nov 2010, at 22:06, Quincey Morris wrote: The other thing I forgot to say earlier is that the new 'panel:shouldEnableURL:' method is explicitly documented to be *ignored* for Save panels, which makes more sense in terms of the OP's original question than the older delegate method. That makes sense. I think having a delegate called panel:shouldShowFilename: that has no influence over which filenames are shown needed some attention! Perhaps it would make more sense to have implemented this solely in the NSOpenPanel class? Same goes for the new panel:shouldEnableURL: delegate? Stephen ___ 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/stephen.blinkhorn%40audiospillage.com This email sent to stephen.blinkh...@audiospillage.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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSSavePanel panel:shouldShowFilename:
On Nov 15, 2010, at 18:48, Erik Buck wrote: > Mac OS 7,8,9 had no delegates at all. Cocoa was introduced with Mac OS X. > Before that, the technology had nothing to do with Mac OS (other than > Rhapsody pre-release and server) and was called Yellow Box. Before that it > was Openstep, and before that NeXTstep. The whole system including Interface > Builder and Objective-C shipped commercially as NeXTstep 0.8 in 1988. Oops, yes, silly of me to have said that about earlier Mac OS. I think what I was trying to say was that there may have been a time when the Save dialog didn't show files, or didn't show all files, (though I don't remember for sure), which might have had something to do with the Mac OS X delegate eventually being designed to control what files were shown. Or maybe not. However, the click-to-prefill thing did precede Cocoa, as a 3rd-party hack. The other thing I forgot to say earlier is that the new 'panel:shouldEnableURL:' method is explicitly documented to be *ignored* for Save panels, which makes more sense in terms of the OP's original question than the older delegate method. ___ 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
Re: NSSavePanel panel:shouldShowFilename:
Thanks for the comprehensive replies. On 15 Nov 2010, at 17:47, Graham Cox wrote: On 16/11/2010, at 10:41 AM, Stephen Blinkhorn wrote: Returning NO for NSSavePanel's panel:shouldShowFilename: delegate will grey out/de-activate an item in the file browser but the item can still be selected and doing so copies the file name string into the Save As: text field. Is this the expected behaviour? I'd expect that returning NO would prevent the user from selecting that item in any way. Which it does for folders at least. The SAVE panel always greys out all filenames, since you're not choosing a file, but saving one. As a convenience, it copies the name of anything you click - occasionally this is handy but it is somewhat odd (but clearly intentional) behaviour really. So I suspect that the delegate method is not contributing to the filename situation, only to stop you going into subfolders. --Graham ___ 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
