Problem with NSDatePicker in popover
My Mac OS application has an NSDatePicker object in a popover. When the popover opens, the date picker works perfectly. However, when I detach the popover to its own window, the date picker no longer highlights the selected date picker element. The date picker still works perfectly in all other respects: I can use the tab key to select different date picker elements (since they aren't highlighted, I have to count the number of tab presses in my head to know which element is selected). I can use the up-down arrows or even type a new value for the year, month or day to change the value. I can tab on out to the next key view. I can even tab around the entire key view loop and back to the date picker, and then set its values again. The associated instance variable's value is properly udpated every time. But the selected date picker element is not highlighted. Actually, when I first detach the popover, I very briefly see the first date element highlighted, but it immediately unhighlights. My -detachableWindowForPopover: delegate method seems to work correctly, but it looks as if something happens after that to make the highlighting in the date picker go away. NSLog calls confirm that the date picker is enabled and its date picker cell is selected. I have made the date picker the detached window's first responder and the key view loop is set up correctly. I am instantiating separate controllers and views for the anchored popover and the detached popover as per the documentation. Has anybody seen this behavior? Is this enough of a description for anybody to suggest where I should look next for the problem? -- Bill Cheeseman - b...@cheeseman.name ___ 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
NSFileManager createDirectory… confusing docs.
A bit of trouble with the NSFileManager docs for the methods: – createDirectoryAtURL:withIntermediateDirectories:attributes:error: – createDirectoryAtPath:withIntermediateDirectories:attributes:error: Both say: Return Value YES if the directory was created or already exists or NO if an error occurred. Both say: createIntermediates (the BOOL argument) If YES, this method creates any non-existent parent directories as part of creating the directory in url. If NO, this method fails if any of the intermediate parent directories does not exist. Both fail to indicate CLEARLY that the BOOL argument to withIntermediateDirectories must be YES or the to return value to be YES if the directory already exists. Setting argument withIntermediateDirectories to NO causes a return value of NO and an error to be generated. The docs do not seem clear on this. (not to me anyway). If the directory you are creating is also considered an intermediate parent directory, that is just confusing. Can anybody explain to me how this makes any sense? My workaround while using createIntermediates as NO was to check the error code and userInfo. But setting createIntermediates to YES gives no error if the directory exists. ___ 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: NSFileManager createDirectory… confusing docs.
On Feb 23, 2013, at 07:57 , John Joyce dangerwillrobinsondan...@gmail.com wrote: The docs do not seem clear on this. (not to me anyway). Yes, they're not clear on this. If the directory you are creating is also considered an intermediate parent directory, that is just confusing. Presumably, it seemed like a good idea to someone at some time to treat the leaf directory consistently with the intermediate directories, when 'withIntermediateDirectories:' is YES. Or perhaps this was originally just a bug that was overlooked. Can anybody explain to me how this makes any sense? It makes sense as a historical behavioral artifact, but changing the behavior of the existing API might break existing code in hard-to-debug ways. I'd suggest you submit documentation feedback reporting the confusing description. It's likely not a high-priority issue, but OTOH it wouldn't be hard to improve the documentation. ___ 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: Problem with NSDatePicker in popover
On Feb 23, 2013, at 1:35 PM, Keary Suska aksu...@frequentflyerservices.com wrote: Your description suggests that you aren't using separate UI elements for the window and the popover as required by the docs...? When I said I am instantiating separate controllers and views for the anchored popover and the detached popover as per the documentation, I meant that I alloc and init separate view controllers for the anchored popover and for the detached popover window. The anchored popover has one view controller. The new view controller for the detached popover window initializes itself by loading the nib file for the view, and I assign the new view as the content view of the new popover window. I believe that results in separate UI elements for the popover and the window. I even have to explicitly set the values in the new UI elements to match the values they had in the anchored popover -- otherwise, the new UI elements are empty. The only substantive difference between my application and Apple's Popover sample code is that Apple instantiates both popover view controllers in the mainmenu nib file, both of them based on the same NSView subclass. I instantiate my two popover view controllers separately in code, both of them based on the same NSView subclass. I instantiate the new detached popover window's view controller lazily in the -detachableWindowForPopover: delegate method. My way, if the user never creates a detached popover window by dragging the anchored popover away from the parent window, I never have to create its view controller and view. Did I understand you correctly? -- Bill Cheeseman - b...@cheeseman.name -- Bill Cheeseman - b...@cheeseman.name ___ 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: Problem with NSDatePicker in popover
On Feb 23, 2013, at 1:35 PM, Keary Suska aksu...@frequentflyerservices.com wrote: Your description suggests that you aren't using separate UI elements for the window and the popover as required by the docs...? I just discovered that Apple's Popover sample code exhibits exactly the same problem when I add a date picker to its popover view! The date picker looks and works as it should when the popover is anchored to its parent window, but it does not highlight its selected date picker elements after the popover is dragged out to its own detached window. This strongly suggests that there is a bug in NSDatePicker. -- Bill Cheeseman - b...@cheeseman.name ___ 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: Problem with NSDatePicker in popover
On Feb 23, 2013, at 2:46 PM, William J. Cheeseman wjcheese...@gmail.com wrote: I just discovered that Apple's Popover sample code exhibits exactly the same problem when I add a date picker to its popover view! The date picker looks and works as it should when the popover is anchored to its parent window, but it does not highlight its selected date picker elements after the popover is dragged out to its own detached window. This strongly suggests that there is a bug in NSDatePicker. Using Apple's Popover example with a date picker added to its popover view, I made MyWindowController the delegate of the popover view and implemented the -windowDidBecomeKey: delegate method. In it, I test whether the window that is becoming key is the detached popover window, and if it is I call sleep(1). Then, when I run the application and detach the popover to its own window, the first date picker element is properly highlighted for one second. Then the highlighting disappears and at the same moment the original parent window loses its key window appearance. So, it's something about the window connection that's causing the misbehavior, but I can't seem to put my finger on it conceptually. -- Bill Cheeseman - b...@cheeseman.name ___ 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: Problem with NSDatePicker in popover
On Feb 23, 2013, at 3:32 PM, William J. Cheeseman wjcheese...@gmail.com wrote: Using Apple's Popover example with a date picker added to its popover view, I made MyWindowController the delegate of the popover view Correction: I made MyWindowController the delegate of the detachedWindow object in MyMenu.xib. When a popover is still anchored to its parent window, the popover view's window is the parent window -- which makes sense, when you think about it, because a popover is just another view in the main window. When the popover is detached, the new, separate popover view's window is the detached popover window. -- Bill Cheeseman - b...@cheeseman.name ___ 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: Problem with NSDatePicker in popover
On Feb 23, 2013, at 4:04 PM, William J. Cheeseman wjcheese...@gmail.com wrote: When a popover is still anchored to its parent window, the popover view's window is the parent window -- which makes sense, when you think about it, because a popover is just another view in the main window. When the popover is detached, the new, separate popover view's window is the detached popover window. And now, simply by fooling around, I have discovered that you can solve the problem at runtime by clicking in the Finder or some other application and then clicking back in the detached popover window. But when I try to profit from this observation by making the parent window key after the detached popover window becomes key, and then immediately (or even after a delay) making the popover window key again, the application goes into the spinning rainbow world and crashes after a while -- both in my application and in Apple's Popover sample application. That's enough for me for today. -- Bill Cheeseman - b...@cheeseman.name ___ 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: iOS books, etc for experienced OSX programmers
Yeah, that'd be my bet as well. It's a fairly new technology. Cheers, -- Uli Kusterer The Witnesses of TeachText are everywhere... http://www.zathras.de On 22.02.2013, at 15:37, Koen van der Drift koenvanderdr...@gmail.com wrote: One thing I'm not sure about yet is the use of 'storyboards'. Apple uses it in their tutorial, but the two books I mentioned seem to hardly touch on it. Maybe it is too new to have been included inthose books? ___ 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: iOS books, etc for experienced OSX programmers
Both Xcode 4 Unleashed and its 4.5 supplement give extended attention to storyboards. — F -- Fritz Anderson Xcode 4 Unleashed: 4.5 supplement for free! http://www.informit.com/store/xcode-4-unleashed-9780672333279 On 23 Feb 2013, at 4:08 PM, Uli Kusterer witness.of.teacht...@gmx.net wrote: Yeah, that'd be my bet as well. It's a fairly new technology. ... On 22.02.2013, at 15:37, Koen van der Drift koenvanderdr...@gmail.com wrote: One thing I'm not sure about yet is the use of 'storyboards'. Apple uses it in their tutorial, but the two books I mentioned seem to hardly touch on it. Maybe it is too new to have been included inthose books? ___ 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: NSFileManager createDirectory… confusing docs.
On Feb 24, 2013, at 3:45 AM, Quincey Morris quinceymor...@rivergatesoftware.com wrote: On Feb 23, 2013, at 07:57 , John Joyce dangerwillrobinsondan...@gmail.com wrote: The docs do not seem clear on this. (not to me anyway). Yes, they're not clear on this. If the directory you are creating is also considered an intermediate parent directory, that is just confusing. Presumably, it seemed like a good idea to someone at some time to treat the leaf directory consistently with the intermediate directories, when 'withIntermediateDirectories:' is YES. Or perhaps this was originally just a bug that was overlooked. I'm going with this one, but as a documentation bug. Can anybody explain to me how this makes any sense? It makes sense as a historical behavioral artifact, but changing the behavior of the existing API might break existing code in hard-to-debug ways. True, but that generally means a new method or a set of release notes when it changes. I'd suggest you submit documentation feedback reporting the confusing description. It's likely not a high-priority issue, but OTOH it wouldn't be hard to improve the documentation. I have sent this. On multiple occasions, including yesterday. ___ 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: NSSavePanel problem
Post a crash log? Did you run with zombies on? -- Jon On Feb 23, 2013, at 6:14 PM, Peter Hudson peter.hud...@me.com 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
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.AppKit0x92cea55f -[NSSavePanel runModal] + 389 31 WattWenn0x0011d5c4 -[SSDayOutOfDaysSetupPanel(EXPORT_SUPPORT) exportDayOutOfDaysReportToHTML:] + 692 (SSDayOutOfDaysSetupPanel.m:1250) 32 libobjc.A.dylib
Re: NSSavePanel problem
On 24/02/2013, at 10:49 AM, Peter Hudson peter.hud...@me.com 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
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 graham@bigpond.com wrote: On 24/02/2013, at 10:49 AM, Peter Hudson peter.hud...@me.com 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: NSFileManager createDirectory… confusing docs.
On Feb 23, 2013, at 9:57 AM, John Joyce wrote: A bit of trouble with the NSFileManager docs for the methods: – createDirectoryAtURL:withIntermediateDirectories:attributes:error: – createDirectoryAtPath:withIntermediateDirectories:attributes:error: Both say: Return Value YES if the directory was created or already exists or NO if an error occurred. Both say: createIntermediates (the BOOL argument) If YES, this method creates any non-existent parent directories as part of creating the directory in url. If NO, this method fails if any of the intermediate parent directories does not exist. Both fail to indicate CLEARLY that the BOOL argument to withIntermediateDirectories must be YES or the to return value to be YES if the directory already exists. Setting argument withIntermediateDirectories to NO causes a return value of NO and an error to be generated. The docs do not seem clear on this. (not to me anyway). If the directory you are creating is also considered an intermediate parent directory, that is just confusing. Can anybody explain to me how this makes any sense? My workaround while using createIntermediates as NO was to check the error code and userInfo. But setting createIntermediates to YES gives no error if the directory exists. This probably doesn't explain anything, but these semantics match the difference between the commands mkdir and mkdir -p. When given a path where any of the intermediate directories doesn't exist or where the final directory does exist, mkdir will fail. It's the strict version which does only and exactly what was requested (creating a directory at a specific path) and no more (doesn't create intermediate directories). mkdir -p is the relaxed version which means, more or less, just make sure there's a directory at this path, no matter which directories you do or don't need to create. Regards, Ken ___ 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 peter.hud...@me.com 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
On Feb 23, 2013, at 7:40 PM, Peter Hudson peter.hud...@me.com 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 graham@bigpond.com wrote: On 24/02/2013, at 10:49 AM, Peter Hudson peter.hud...@me.com 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:12 , Andy Lee ag...@mac.com 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: Problem with NSDatePicker in popover
On 24/02/2013, at 8:04 AM, William J. Cheeseman wjcheese...@gmail.com wrote: When a popover is still anchored to its parent window, the popover view's window is the parent window -- which makes sense, when you think about it, because a popover is just another view in the main window. Are you sure about that? I'm not... it would make sense to me if the popover window was a separate window, a child of the original window. That's how it acts and behaves. For example if the popover falls outside the bounds of the original view or window, it has its own shadow etc, and is unclipped by the original window. The internal pointers to the view's window might return some other window of course, but I don't think so - I have tried for example, to attach a sheet to a popover by asking for the view's -window as the sheet's parent and it attached the sheet to the popover. Turned out to be a bad idea, but it worked, sort of. When the popover is detached, the new, separate popover view's window is the detached popover window. Do you need to call -makeKeyAndOrderFront: on the detached window? --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 Feb 23, 2013, at 9:57 PM, Quincey Morris quinceymor...@rivergatesoftware.com wrote: On Feb 23, 2013, at 18:12 , Andy Lee ag...@mac.com 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
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 quinceymor...@rivergatesoftware.com wrote: On Feb 23, 2013, at 18:12 , Andy Lee ag...@mac.com 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: Custom control with 4 vertical sliders
I've been following this thread because I have a similar application in mind, displaying 6 sets (groupings, not NSSets) consisting of a label with slider and textview, both bound to an ivar. It seems so simple: create a custom view with one set, duplicate it to make 6 such custom views, and place them all into another custom view. I'm not advanced enough to understand why there's a discussion. On the other hand, there seems to be interest in more complex ways, which implies that there are advantages in them that I don't see. Specifically, I don't see advantage in going on with collection views or boxes, and I don't know what you would do with a subclass (of what?). What am I missing? It must be elementary. On Feb 16, 2013, at 10:18 AM, Gordon Apple wrote: Don¹t use NSMatrix. Use NSCollectionView. I have a popover containing a collection view with sliders and all kinds of other stuff. Depending on what you are doing, you may need to make the thing create a new view for every collection class element instead of just replicating the prototype. (I have individual QTmovie thumbnails playing in mine.) You will need to subclass the collection view to do this. However, from your description, that should not be necessary. The standard prototype view should work without subclassing the collection view. On 2/16/13 4:00 AM, cocoa-dev-requ...@lists.apple.com cocoa-dev-requ...@lists.apple.com wrote: I sometimes find that trying to subclass existing classes such as NSCell is more trouble that it's worth, unless you really need your custom cell to be used anywhere a cell can be used, e.g. buttons, matrices, list rows, etc. If you just want a particular custom control that doesn't need that degree of reusability, subclassing NSView or NSControl is always a lot easier. In this case, if NSSlider isn't suitable, just make a custom view for your custom slider, then add it four times to another custom view that handles the set of sliders as needed. ___ 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/pu56ucla62%40alumni.purdue.edu This email sent to pu56ucl...@alumni.purdue.edu ___ 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 j...@ambrosiasw.com 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 ag...@mac.com 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: Custom control with 4 vertical sliders
On 24/02/2013, at 4:59 PM, N!K pu56ucl...@alumni.purdue.edu wrote: It seems so simple: create a custom view with one set, duplicate it to make 6 such custom views, and place them all into another custom view. Well, you have to consider that NSView does not support NSCopying, though there are fairly simple ways around that, so duplicate it isn't as easy as it sounds if you're taking about doing this in code. Doing it in IB, fairly straightforward, except that these days IB no longer supports custom plug-ins, so it's not always possible to see what you're doing - you have to manipulate empty boxes instead of a true representation of your custom view. I'm not advanced enough to understand why there's a discussion. Because there are Apple-provided classes that appear to get you a lot of what you need. It's usually better to use an Apple-designed class if there is one, because it's been debugged and in most cases, well-designed. The problem comes where there is a class that looks like it gets you a lot of what you need, but then needs a lot of subclassing and overriding to get the last mile. The question is at what point you draw the line and say it's better to start from something more basic, like NSView. That line will be in different places for different programmers with different levels of experience, hence the discussion. --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
