Re: NSButton (radio button) not calling action when overlapped by invisible NSButton?
On 10 Mar 2015, at 5:01 PM, Aandi Inston aa...@quite.com wrote: The dialogs are frequently very complex, with areas showing different groups of controls according to context. Individual controls are shown/hidden by the higher level code to make this work. Radio buttons are naturally implemented as an NSButton with suitable style. [“Hidden” controls seem sometimes to intercept clicks in visible ones.] Can anyone make any suggestions about whether this diagnosis has any ring of truth, and how to fix or further investigate it? It’s plausible. The canonical solution to having a suite of control layouts to be hidden or revealed as needed is to wrap them in an NSTabView, hide the tabs, and switch among them programmatically. — 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: Weird crashes on Yosemite
On 13/03/15 16:11, Peter Hudson wrote: Thanks for these suggestion Steve and Markus. The table datasource and delegate code has been running very sweetly for a number of years and has not been changed since it was written some time back. We had a similar crashs when running our app on Yosemite (even with unchanged code compiled against the 10.9 SDK). The table wind-down behavior seems to have changed slightly which can trigger this in code that worked fine forever. Regards Markus -- __ Markus Spoettl ___ 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: NSButton (radio button) not calling action when overlapped by invisible NSButton?
(This is odd. I did not receive a copy of my post and therefore assumed it had not posted. Clearly it did as you were kind enough to reply) Happily I found the solution. This list earlier helped me to understand a problem which appeared in recent Mac OS, where radio buttons would all work as an automatic group (clicking one would turn off all the others), which is a pity if one wanted multiple groups. This turned out to be a new feature of Mac OS likely to affect other control libraries; triggered when a number of conditions were met including having the same actions. Which, since these are generated by a control library, they all had. The solution to THAT issue was to wrap each radio button in its own parent NSView, and place the NSView in the dialog rather than the radio button. Of course this requires managing two controls: the NSView (e.g. for moving the control) and the NSButton (e.g. for checking the button). The problem was that HIDING the control was still being applied to the NSButton. The NSView was remaining visible (though having no visual aspect) and intercepting clicks if it happened to be on top. The solution is of course to hide the NSView instead of the NSButton. Converting to an NSTabView would be difficult because the higher level control library manages visibility and expects to be able to do so at the level of individual controls. But it may be prudent to always disable NSControl based controls when they are hidden. Hope this helps anyone who finds a similar issue. ___ 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: Weird crashes on Yosemite
Your code may not have changed, but Apple's code has - are you still using reference counting? Because I'm willing to bet that NSTableView isn't, and I filed rdar://17733863 over a situation very much like this one - the workaround was to setDelegate:nil earlier than you might think necessary. On Mar 13, 2015, at 8:11 AM, Peter Hudson peter.hud...@me.com wrote: Thanks for these suggestion Steve and Markus. The table datasource and delegate code has been running very sweetly for a number of years and has not been changed since it was written some time back. The table datasource in this case is completely central to the program - and I never change the datasource or delegate for this table. That said, the suggestions are interesting - I will try out the debugging ideas. My problem is, I can’t reproduce a crash to order ! This one happened after the user had been working for three hours. Peter On 13 Mar 2015, at 14:55, Steve Mills sjmi...@mac.com wrote: On Mar 13, 2015, at 09:46:36, Peter Hudson peter.hud...@me.com wrote: Crashed Thread:0 Dispatch queue: com.apple.main-thread Exception Type:EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x objc_msgSend() selector name: objectAtIndex: Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libobjc.A.dylib 0x938810ab objc_msgSend + 27 1 com.apple.AppKit0x9184a305 -[NSTableView _dataSourceValueForColumn:row:] + 69 2 com.apple.AppKit0x9194e127 -[NSTableView preparedCellAtColumn:row:] + 385 3 com.apple.AppKit0x917efc91 -[NSTableView _dirtyVisibleCellsForKeyStateChange] + 878 What do you have set as the dataSource for the table? Is it still valid when the window owning the table becomes key? Is it owned by some object that might be in a weak property instead of strong? (Although you would probably see that right away when you debugged it.) Have you run static analysis on the project? Have you turned on Scribble, Guard Edges, and Guard Malloc in your scheme while debugging? Some of those can sometimes help force bugs to the surface. -- Steve Mills Drummer, Mac geek On 13/03/15 15:46, Peter Hudson wrote: Any comments or suggestions gratefully received ! Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libobjc.A.dylib 0x938810ab objc_msgSend + 27 1 com.apple.AppKit 0x9184a305 -[NSTableView _dataSourceValueForColumn:row:] + 69 2 com.apple.AppKit 0x9194e127 -[NSTableView preparedCellAtColumn:row:] + 385 3 com.apple.AppKit 0x917efc91 -[NSTableView _dirtyVisibleCellsForKeyStateChange] + 878 4 com.apple.AppKit 0x917ef6de -[NSTableView _windowChangedKeyState] + 323 This looks like a table's delegate or datasource has been disposed off while the table still uses it. Make sure to set table delegates/datasources to nil when the object being used as delegate/datasource is deallocated. Regards Markus -- ___ 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/lrucker%40vmware.com 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
Full-screen mode broken after upgrading to Yosemite
[My first attempted post was 3KB too big.]
I restarted work on my web browser project from a few months ago. Since then, I
upgraded my MacBook Air from Mavericks to Yosemite, and Xcode from 6.0 to 6.1.1
(and, as of yesterday, 6.2). The deployment level is still (implicitly) 10.9,
but the SDK was automatically upgraded to 10.10.
My main browser window supports full-screen and optimized zoom. In Yosemite,
those two functions share the green titlebar button. When I activate
full-screen mode, with either the green button or the menu item, the window
freezes without any visual change. The window can’t be moved or shifted out of
the way upon switching apps. (The window doesn’t corrupt other Spaces, though.)
The rest of the app still works, but new windows are always beneath the frozen
one.
When trying full-screen, this appears on the Xcode debug log:
2015-03-13 17:17:18.850 Prairie[7319:1920249] *** Assertion failure in
-[PrBrowserController windowWillUseStandardFrame:defaultFrame:],
/Users/.../Prairie/PrBrowserController.m:297
2015-03-13 17:17:18.856 Prairie[7319:1920249] An uncaught exception was raised
2015-03-13 17:17:18.857 Prairie[7319:1920249] Standard web-browser window
size too tall.
2015-03-13 17:17:18.894 Prairie[7319:1920249] (
0 CoreFoundation 0x7fff8417d66c
__exceptionPreprocess + 172
1 libobjc.A.dylib 0x7fff896c076e
objc_exception_throw + 43
2 CoreFoundation 0x7fff8417d44a
+[NSException raise:format:arguments:] + 106
3 Foundation 0x7fff9062d3a9
-[NSAssertionHandler
handleFailureInMethod:object:file:lineNumber:description:] + 195
4 Prairie 0x0001000118f1
-[PrBrowserController windowWillUseStandardFrame:defaultFrame:] + 2545
5 AppKit 0x7fff90f60bf5 -[NSWindow
_frameForFullScreenMode] + 735
6 AppKit 0x7fff914fa0a4
__62-[_NSWindowFullScreenTransition
setWindowToHaveFullScreenSize]_block_invoke + 71
7 AppKit 0x7fff90d6f6b3
NSPerformWithScreenUpdatesDisabled + 65
8 AppKit 0x7fff914fa057
-[_NSWindowFullScreenTransition setWindowToHaveFullScreenSize] + 73
9 AppKit 0x7fff90f0ba6e
-[_NSFullScreenTransition
enterFullScreenTransitionWithOptions:animated:activatingIt:] + 1059
10 AppKit 0x7fff90f0aded -[NSWindow
_enterFullScreenMode:animating:activating:] + 294
11 libsystem_trace.dylib 0x7fff843b2cd7
_os_activity_initiate + 75
12 AppKit 0x7fff90e45b71
-[NSApplication sendAction:to:from:] + 452
13 AppKit 0x7fff90e5fcbe -[NSMenuItem
_corePerformAction] + 382
14 AppKit 0x7fff90e5f9dc
-[NSCarbonMenuImpl performActionWithHighlightingForItemAtIndex:] + 114
15 libsystem_trace.dylib 0x7fff843b2cd7
_os_activity_initiate + 75
16 AppKit 0x7fff90ead4e0 -[NSMenu
performActionForItemAtIndex:] + 131
...
)
Why is my optimized-zoom sizing method called during a full-screen adjustment?
After quitting and restarting the app, the resume feature remembers the
window’s state and starts with a broken view. The full-screen is black with the
window’s content in its pre-full-screen size in the middle. The title bar and
toolbar areas are there in the inner window but blank. The top of the screen
has the toolbar with buttons. Going to the top of the screen reveals the title
bar with the red/yellow/green buttons, but the title string is off center,
keeping the same spacing it had pre-full-screen. Undoing full-screen mode works
fine, though!
Here’s my zoom sizing method:
- (NSRect)windowWillUseStandardFrame:(NSWindow *)window
defaultFrame:(NSRect)newFrame {
NSParameterAssert(self.window == window);
// Based on the web content, get the maximum desired width and height.
NSViewWebDocumentView * const view =
self.webView.mainFrame.frameView.documentView;
NSSize const desiredContentSize = NSMakeSize(NSWidth(view.frame),
NSHeight(view.frame) + ((CGFloat)!!self.isLoadingBarVisible *
PrLoadingBarHeight) + ((CGFloat)!!self.isStatusBarVisible *
PrStatusBarHeight));
// Adjust that desired size to what's actually available.
NSRect frame = [window contentRectForFrameRect:newFrame];
frame.size.width = MIN(desiredContentSize.width, frame.size.width);
frame.size.height = MIN(desiredContentSize.height, frame.size.height);
// Adjust to the window's size bounds.
frame = [window frameRectForContentRect:frame];
frame.size.width = MAX(window.minSize.width,
Re: Cocoa GUI app getting slower on MacPro or MacMini when disconnecting all screens
Macs still do that. I needed to get an adapter to get decent performance out of my headless macMini. Am 12.03.2015 um 21:18 schrieb Matthieu Beghin matthieu.beg...@garagecube.com: Yes I do OpenGL… I can’t see any process using CPU, so I was thinking it’s not related, but maybe for some reason the glSwap is blocking for some time… The strange thing is that in Instruments it looks that my threads are not blocked. I will do further investigations on monday. Thx ! Matthieu On 12 Mar 2015, at 16:21, Uli Kusterer witness.of.teacht...@gmx.net wrote: On 11 Mar 2015, at 23:40, Matthieu Beghin matthieu.beg...@garagecube.com wrote: Any idea ? You're not doing anything graphics or OpenGL-related, are you? At least in the old days, Macs would turn off the GPU when no screen was attached, meaning that you'd end up in software emulation when you did any openGL calls. I thought that was different these days, but maybe this reminds you of something you're doing that could cause this slowdown? -- Uli/ ___ 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/georg.seifert%40gmx.de This email sent to georg.seif...@gmx.de ___ 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: Cocoa GUI app getting slower on MacPro or MacMini when disconnecting all screens
I use a flock of Mac Minis as servers. Most if not all run headless. In my experience Finder operations and other apps seem fine. But I seldom if ever run anything terribly graphics intensive. Phil On Mar 13, 2015, at 8:08 PM, Georg Seifert georg.seif...@gmx.de wrote: Macs still do that. I needed to get an adapter to get decent performance out of my headless macMini. Am 12.03.2015 um 21:18 schrieb Matthieu Beghin matthieu.beg...@garagecube.com: Yes I do OpenGL… I can’t see any process using CPU, so I was thinking it’s not related, but maybe for some reason the glSwap is blocking for some time… The strange thing is that in Instruments it looks that my threads are not blocked. I will do further investigations on monday. Thx ! Matthieu On 12 Mar 2015, at 16:21, Uli Kusterer witness.of.teacht...@gmx.net wrote: On 11 Mar 2015, at 23:40, Matthieu Beghin matthieu.beg...@garagecube.com wrote: Any idea ? You're not doing anything graphics or OpenGL-related, are you? At least in the old days, Macs would turn off the GPU when no screen was attached, meaning that you'd end up in software emulation when you did any openGL calls. I thought that was different these days, but maybe this reminds you of something you're doing that could cause this slowdown? -- Uli/ ___ 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/georg.seifert%40gmx.de This email sent to georg.seif...@gmx.de ___ 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/ershler%40cvrti.utah.edu This email sent to ersh...@cvrti.utah.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: Full-screen mode broken after upgrading to Yosemite
On Mar 13, 2015, at 4:29 PM, Daryle Walker dary...@mac.com wrote:
My main browser window supports full-screen and optimized zoom. In Yosemite,
those two functions share the green titlebar button. When I activate
full-screen mode, with either the green button or the menu item, the window
freezes without any visual change. The window can’t be moved or shifted out
of the way upon switching apps. (The window doesn’t corrupt other Spaces,
though.) The rest of the app still works, but new windows are always beneath
the frozen one.
When trying full-screen, this appears on the Xcode debug log:
2015-03-13 17:17:18.850 Prairie[7319:1920249] *** Assertion failure in
-[PrBrowserController windowWillUseStandardFrame:defaultFrame:],
/Users/.../Prairie/PrBrowserController.m:297
2015-03-13 17:17:18.856 Prairie[7319:1920249] An uncaught exception was
raised
2015-03-13 17:17:18.857 Prairie[7319:1920249] Standard web-browser window
size too tall.
You have an assertion in your code. The assertion is failing and thus throwing
an exception. Once that happens, stuff is broken. This is the expected
consequence of an assertion failing or an exception being thrown. The nature
of the resulting brokenness is not predictable or diagnostic.
Why is my optimized-zoom sizing method called during a full-screen adjustment?
Because it's not just for zoom. It's for computing the standard frame.
Here’s my zoom sizing method:
- (NSRect)windowWillUseStandardFrame:(NSWindow *)window
defaultFrame:(NSRect)newFrame {
NSParameterAssert(self.window == window);
// Based on the web content, get the maximum desired width and height.
NSViewWebDocumentView * const view =
self.webView.mainFrame.frameView.documentView;
NSSize const desiredContentSize = NSMakeSize(NSWidth(view.frame),
NSHeight(view.frame) + ((CGFloat)!!self.isLoadingBarVisible *
PrLoadingBarHeight) + ((CGFloat)!!self.isStatusBarVisible *
PrStatusBarHeight));
// Adjust that desired size to what's actually available.
NSRect frame = [window contentRectForFrameRect:newFrame];
frame.size.width = MIN(desiredContentSize.width, frame.size.width);
frame.size.height = MIN(desiredContentSize.height, frame.size.height);
// Adjust to the window's size bounds.
frame = [window frameRectForContentRect:frame];
frame.size.width = MAX(window.minSize.width, frame.size.width);
frame.size.height = MAX(window.minSize.height, frame.size.height);
NSAssert(frame.size.width = newFrame.size.width, @Standard web-browser
window size too wide.);
NSAssert(frame.size.height = newFrame.size.height, @Standard
web-browser window size too tall.);
Why do you think those are legitimate things to assert? Have you checked the
values involved and the inputs to the computation?
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
Trying to hide a NSProgressIndicator upon finishing of table rendering
I am trying to have a progress spinner show upon processing of data, and hide upon completeion of rendering all the columns/rows of my table... The problem is, if I do something like: if (row == lastRow) [self hideSpinner] This does not get called until I physically scroll to the end of my view, as I guess NSTableView is doing some lazy loading. Is there a way to determine when the table has actually finished drawing itself so I can hook into that? Thanks! Patrick J. Collins http://collinatorstudios.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: Weird crashes on Yosemite
I do not have a solution but hopefully i can point you to right direction:
It crashes when the window is trying to become key window. becomeKeyWindow
[NSWindow becomeKeyWindow].
It crashes in _dataSourceValueForColumn:row:
It crashes on selector objectAtIndex:
According to dissasembly column is retrieved and send as a parameter to
crashing function.
For me it looks like there is something wrong with the number of
tableColumns.
Here is Hopper disassembly of [NSTableView preparedCellAtColumn:row:]
loc_28c782:
LODWORD(r13) = 0x0;
if (rbx = 0x0) {
r13 = [r12-_tableColumns objectAtIndex:rbx];
}
var_38 = [r12 _dataSourceValueForColumn:r13 row:r14];
if (r15 == 0x0) {
r15 = [r12 _dataCellForTableColumn:r13 row:r14];
}
Here is Hopper disassembly of [NSTableView _dataSourceValueForColumn:row:]
void * -[NSTableView _dataSourceValueForColumn:row:](void * self, void *
_cmd, void * arg2, long long arg3) {
rax = arg3;
r14 = arg2;
rbx = self;
if ((*(int8_t *)(rbx-_reserved +
*_OBJC_IVAR_$__NSTableViewReserved._tvFlags2 + 0x1) 0x8) != 0x0) {
rdi = rbx-_dataSource;
rdx = rbx;
rcx = r14;
rax = [rdi tableView:rdx objectValueForTableColumn:rcx row:rax];
}
else {
if (([rbx _bindingAdaptor] == 0x0) (r14 != 0x0)) {
if (([r14 _bindingAdaptor] == 0x0) (rbx-_rowDataX
== 0x0)) {
[rbx _printDatasourceWarning];
}
}
LODWORD(rax) = 0x0;
return rax;
}
return rax;
}
On Sat, Mar 14, 2015 at 9:14 AM, Peter Hudson peter.hud...@me.com wrote:
I don't get to the situation where I would need to set the delegate to
zero - the user isn't closing the app down when the crashes occur. The
whole relationship of delegate and datasource is setup when a project is
opened - and remains the same throughout. It simply hoses along the way.
Peter
Original Message
From: Lee Ann Rucker
Sent: Friday, 13 March 2015 19:57
To: Peter Hudson
Cc: Steve Mills; ms_li...@shiftoption.com; Cocoa dev
Subject: Re: Weird crashes on Yosemite
Your code may not have changed, but Apple's code has - are you still using
reference counting? Because I'm willing to bet that NSTableView isn't, and
I filed rdar://17733863 over a situation very much like this one - the
workaround was to setDelegate:nil earlier than you might think necessary.
On Mar 13, 2015, at 8:11 AM, Peter Hudson peter.hud...@me.com wrote:
Thanks for these suggestion Steve and Markus.
The table datasource and delegate code has been running very sweetly for
a number of years and has not been changed since it was written some time
back.
The table datasource in this case is completely central to the program -
and I never change the datasource or delegate for this table.
That said, the suggestions are interesting - I will try out the
debugging ideas.
My problem is, I can’t reproduce a crash to order !
This one happened after the user had been working for three hours.
Peter
On 13 Mar 2015, at 14:55, Steve Mills sjmi...@mac.com wrote:
On Mar 13, 2015, at 09:46:36, Peter Hudson peter.hud...@me.com wrote:
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x
objc_msgSend() selector name: objectAtIndex:
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libobjc.A.dylib 0x938810ab objc_msgSend + 27
1 com.apple.AppKit 0x9184a305 -[NSTableView
_dataSourceValueForColumn:row:] + 69
2 com.apple.AppKit 0x9194e127 -[NSTableView preparedCellAtColumn:row:]
+ 385
3 com.apple.AppKit 0x917efc91 -[NSTableView
_dirtyVisibleCellsForKeyStateChange] + 878
What do you have set as the dataSource for the table? Is it still valid
when the window owning the table becomes key? Is it owned by some object
that might be in a weak property instead of strong? (Although you would
probably see that right away when you debugged it.) Have you run static
analysis on the project? Have you turned on Scribble, Guard Edges, and
Guard Malloc in your scheme while debugging? Some of those can sometimes
help force bugs to the surface.
--
Steve Mills
Drummer, Mac geek
On 13/03/15 15:46, Peter Hudson wrote:
Any comments or suggestions gratefully received !
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libobjc.A.dylib 0x938810ab objc_msgSend + 27
1 com.apple.AppKit 0x9184a305 -[NSTableView
_dataSourceValueForColumn:row:] + 69
2 com.apple.AppKit 0x9194e127 -[NSTableView preparedCellAtColumn:row:]
+ 385
3 com.apple.AppKit 0x917efc91 -[NSTableView
_dirtyVisibleCellsForKeyStateChange] + 878
4 com.apple.AppKit 0x917ef6de -[NSTableView _windowChangedKeyState] +
323
This looks like a table's delegate or datasource has been disposed
NSStatusItem Popover doesn't work in Full Screen mode
If I have a NSStatusItem which brings up a popover when tapped, it works
normally and it works in Full Screen mode if our app is the one being shown.
But if you are in full screen mode with another app, it doesn’t show up.
I’d like to get some ideas on what to do here.
-(void) statusItemSelected:(NSButton*)sender
{
if (informantStatusPopover.isShown)
{
[informantStatusPopover close];
informantStatusPopover = nil;
}
else
{
PIMenuItemTodayViewController* focusViewSidebar =
[[PIMenuItemTodayViewController alloc]
initWithNibName:@PIMenuItemTodayViewController bundle: [NSBundle mainBundle]];
informantStatusPopover = [[NSPopover alloc] init];
informantStatusPopover.contentViewController = focusViewSidebar;
informantStatusPopover.contentSize = NSMakeSize(320, 480);
informantStatusPopover.behavior = NSPopoverBehaviorTransient;
informantStatusPopover.delegate = self;
[informantStatusPopover showRelativeToRect:[sender frame]
ofView:sender preferredEdge:NSMinYEdge];
}
}
Alex Kac - President and Founder
Web Information Solutions, Inc.
Forgiveness is not an occasional act: it is a permanent attitude.
-- Dr. Martin Luther King
___
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: Weird crashes on Yosemite
I don't get to the situation where I would need to set the delegate to zero - the user isn't closing the app down when the crashes occur. The whole relationship of delegate and datasource is setup when a project is opened - and remains the same throughout. It simply hoses along the way. Peter Original Message From: Lee Ann Rucker Sent: Friday, 13 March 2015 19:57 To: Peter Hudson Cc: Steve Mills; ms_li...@shiftoption.com; Cocoa dev Subject: Re: Weird crashes on Yosemite Your code may not have changed, but Apple's code has - are you still using reference counting? Because I'm willing to bet that NSTableView isn't, and I filed rdar://17733863 over a situation very much like this one - the workaround was to setDelegate:nil earlier than you might think necessary. On Mar 13, 2015, at 8:11 AM, Peter Hudson peter.hud...@me.com wrote: Thanks for these suggestion Steve and Markus. The table datasource and delegate code has been running very sweetly for a number of years and has not been changed since it was written some time back. The table datasource in this case is completely central to the program - and I never change the datasource or delegate for this table. That said, the suggestions are interesting - I will try out the debugging ideas. My problem is, I can’t reproduce a crash to order ! This one happened after the user had been working for three hours. Peter On 13 Mar 2015, at 14:55, Steve Mills sjmi...@mac.com wrote: On Mar 13, 2015, at 09:46:36, Peter Hudson peter.hud...@me.com wrote: Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x objc_msgSend() selector name: objectAtIndex: Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libobjc.A.dylib 0x938810ab objc_msgSend + 27 1 com.apple.AppKit 0x9184a305 -[NSTableView _dataSourceValueForColumn:row:] + 69 2 com.apple.AppKit 0x9194e127 -[NSTableView preparedCellAtColumn:row:] + 385 3 com.apple.AppKit 0x917efc91 -[NSTableView _dirtyVisibleCellsForKeyStateChange] + 878 What do you have set as the dataSource for the table? Is it still valid when the window owning the table becomes key? Is it owned by some object that might be in a weak property instead of strong? (Although you would probably see that right away when you debugged it.) Have you run static analysis on the project? Have you turned on Scribble, Guard Edges, and Guard Malloc in your scheme while debugging? Some of those can sometimes help force bugs to the surface. -- Steve Mills Drummer, Mac geek On 13/03/15 15:46, Peter Hudson wrote: Any comments or suggestions gratefully received ! Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libobjc.A.dylib 0x938810ab objc_msgSend + 27 1 com.apple.AppKit 0x9184a305 -[NSTableView _dataSourceValueForColumn:row:] + 69 2 com.apple.AppKit 0x9194e127 -[NSTableView preparedCellAtColumn:row:] + 385 3 com.apple.AppKit 0x917efc91 -[NSTableView _dirtyVisibleCellsForKeyStateChange] + 878 4 com.apple.AppKit 0x917ef6de -[NSTableView _windowChangedKeyState] + 323 This looks like a table's delegate or datasource has been disposed off while the table still uses it. Make sure to set table delegates/datasources to nil when the object being used as delegate/datasource is deallocated. Regards Markus -- ___ 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/lrucker%40vmware.com 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
Re: setting table view rows and columns?
Normally you just set up the column titles in IB. The titles are actually the tableColumn.headerCell.stringValue property, displayed in a NSTableHeaderView. If you are setting these programmatically, you should probably do tat as part of the table controller's setup, not every time the dataSource method is called (which is at least once per row). I cannot figure out how to do this in IB.. I went into the View Controller Scene, and found my table view, selected nested table cell view for a column.. Double clicked on the cell, and typed the header text... but when I build my app, it's blank. I am able to populate my table with data, I just can't seem to get a header to show up. Maybe I should just use labels above the table?? Patrick J. Collins http://collinatorstudios.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: setting table view rows and columns?
On 13 Mar 2015, at 5:26 pm, Patrick J. Collins patr...@collinatorstudios.com wrote: I cannot figure out how to do this in IB.. I went into the View Controller Scene, and found my table view, selected nested table cell view for a column.. Double clicked on the cell, and typed the header text... but when I build my app, it's blank. Just double-click the column header title and type in the title you want. Or select the table column in the hierarchical view and enter text in the Title field of the editor panel. The column's table cell is NOT the header cell. The headerCell isn't exposed directly in IB, set its string as above. --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: setting table view rows and columns?
On Mar 13, 2015, at 02:18:00, Patrick J. Collins patr...@collinatorstudios.com wrote: The inspector shows the text set under 'Title', yet when I build, there is no text.. it's all blank.. Quite frustrating. You're sure you have an NSTableColumn selected, not Table View Cell that's in the column? Both have a Title field in the inspector. I am thinking labels is the way to go anyway because I want the header to stay locked when I scroll.. No. The table header will do exactly that. The column headers can also be clicked to change the sort column and sort order. And they can be dragged to rearrange the columns if you choose to allow that. And that's where the user can resize columns. -- Steve Mills Drummer, Mac geek ___ 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: setting table view rows and columns?
Yeah I did that.. Just double-click the column header title and type in the title you want. Or select the table column in the hierarchical view and enter text in the Title field of the editor panel. The inspector shows the text set under 'Title', yet when I build, there is no text.. it's all blank.. Quite frustrating. I am thinking labels is the way to go anyway because I want the header to stay locked when I scroll.. Patrick J. Collins http://collinatorstudios.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
Weird crashes on Yosemite
Hi All I have ongoing crash problems - and I have no idea where to start looking around for an answer ! The application is built using Xcode 6.1 on 10.10.2. ( and was running on a new Macbook Pro running 10.10.2 ) The users have given me a detailed account of what they were doing when the crash below occurred - and however hard I try I cannot get it to happen again. In fact this has been an ongoing picture. The app just blows up from time to time, in different places, and I get a dump similar to below - i.e. WW is at the bottom of the stack and then does not appear anywhere in the stack, and then we get an invalid access from some Cocoa method or other. Any comments or suggestions gratefully received ! Peter Process: WattWenn [1915] Path: /Applications/WattWenn.app/Contents/MacOS/WattWenn Identifier:WattWenn Version: V 3.3 [ 0364 20141129 HE ] (???) Code Type: X86 (Native) Parent Process:??? [1] Responsible: WattWenn [1915] User ID: 1311087776 Date/Time: 2015-03-12 19:42:26.822 + OS Version:Mac OS X 10.10.2 (14C1510) Report Version:11 Anonymous UUID:FC5F8E83-9560-DB0D-7F5B-9EB89DE84CCF Sleep/Wake UUID: 7A3AA95E-945B-46D5-851B-AC3ECC8D4643 Time Awake Since Boot: 25000 seconds Time Since Wake: 2 seconds Crashed Thread:0 Dispatch queue: com.apple.main-thread Exception Type:EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x VM Regions Near 0x: -- shared memory a000-b000 [4K] r-x/r-x SM=SHM Application Specific Information: objc_msgSend() selector name: objectAtIndex: Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libobjc.A.dylib 0x938810ab objc_msgSend + 27 1 com.apple.AppKit0x9184a305 -[NSTableView _dataSourceValueForColumn:row:] + 69 2 com.apple.AppKit0x9194e127 -[NSTableView preparedCellAtColumn:row:] + 385 3 com.apple.AppKit0x917efc91 -[NSTableView _dirtyVisibleCellsForKeyStateChange] + 878 4 com.apple.AppKit0x917ef6de -[NSTableView _windowChangedKeyState] + 323 5 com.apple.AppKit0x917ee2d1 -[NSView _windowChangedKeyState] + 276 6 com.apple.AppKit0x917ee2d1 -[NSView _windowChangedKeyState] + 276 7 com.apple.AppKit0x917ef46f -[NSScrollView _windowChangedKeyState] + 50 8 com.apple.AppKit0x917ee2d1 -[NSView _windowChangedKeyState] + 276 9 com.apple.AppKit0x917ee2d1 -[NSView _windowChangedKeyState] + 276 10 com.apple.AppKit0x917ee2d1 -[NSView _windowChangedKeyState] + 276 11 com.apple.AppKit0x917ee2d1 -[NSView _windowChangedKeyState] + 276 12 com.apple.AppKit0x917ee16a -[NSFrameView _windowChangedKeyState] + 101 13 com.apple.AppKit0x91e383b0 -[NSThemeFrame _windowChangedKeyState] + 51 14 com.apple.AppKit0x917edca9 -[NSWindow _setFrameNeedsDisplay:] + 182 15 com.apple.AppKit0x917edb03 -[NSWindow(NSWindow_Theme) acquireKeyAppearance] + 281 16 com.apple.AppKit0x917ed1e4 -[NSWindow becomeKeyWindow] + 1493 17 com.apple.AppKit0x917ec652 -[NSWindow _changeKeyAndMainLimitedOK:] + 848 18 com.apple.AppKit0x91eab4fb -[NSWindow _reallySendEvent:] + 10485 19 com.apple.AppKit0x91891948 -[NSWindow sendEvent:] + 484 20 com.apple.AppKit0x9183f3fd -[NSApplication sendEvent:] + 4758 21 com.apple.AppKit0x916b908c -[NSApplication run] + 1003 22 com.apple.AppKit0x916a23f0 NSApplicationMain + 2082 23 WattWenn0x000e736b main + 43 24 WattWenn0x000e6e55 start + 53 ___ 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: Weird crashes on Yosemite
On 13/03/15 15:46, Peter Hudson wrote: Any comments or suggestions gratefully received ! Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libobjc.A.dylib 0x938810ab objc_msgSend + 27 1 com.apple.AppKit0x9184a305 -[NSTableView _dataSourceValueForColumn:row:] + 69 2 com.apple.AppKit0x9194e127 -[NSTableView preparedCellAtColumn:row:] + 385 3 com.apple.AppKit0x917efc91 -[NSTableView _dirtyVisibleCellsForKeyStateChange] + 878 4 com.apple.AppKit0x917ef6de -[NSTableView _windowChangedKeyState] + 323 This looks like a table's delegate or datasource has been disposed off while the table still uses it. Make sure to set table delegates/datasources to nil when the object being used as delegate/datasource is deallocated. Regards Markus -- __ Markus Spoettl ___ 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: Weird crashes on Yosemite
On Mar 13, 2015, at 09:46:36, Peter Hudson peter.hud...@me.com wrote: Crashed Thread:0 Dispatch queue: com.apple.main-thread Exception Type:EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x objc_msgSend() selector name: objectAtIndex: Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libobjc.A.dylib 0x938810ab objc_msgSend + 27 1 com.apple.AppKit 0x9184a305 -[NSTableView _dataSourceValueForColumn:row:] + 69 2 com.apple.AppKit 0x9194e127 -[NSTableView preparedCellAtColumn:row:] + 385 3 com.apple.AppKit 0x917efc91 -[NSTableView _dirtyVisibleCellsForKeyStateChange] + 878 What do you have set as the dataSource for the table? Is it still valid when the window owning the table becomes key? Is it owned by some object that might be in a weak property instead of strong? (Although you would probably see that right away when you debugged it.) Have you run static analysis on the project? Have you turned on Scribble, Guard Edges, and Guard Malloc in your scheme while debugging? Some of those can sometimes help force bugs to the surface. -- Steve Mills Drummer, Mac geek ___ 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: Weird crashes on Yosemite
Thanks for these suggestion Steve and Markus. The table datasource and delegate code has been running very sweetly for a number of years and has not been changed since it was written some time back. The table datasource in this case is completely central to the program - and I never change the datasource or delegate for this table. That said, the suggestions are interesting - I will try out the debugging ideas. My problem is, I can’t reproduce a crash to order ! This one happened after the user had been working for three hours. Peter On 13 Mar 2015, at 14:55, Steve Mills sjmi...@mac.com wrote: On Mar 13, 2015, at 09:46:36, Peter Hudson peter.hud...@me.com wrote: Crashed Thread:0 Dispatch queue: com.apple.main-thread Exception Type:EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x objc_msgSend() selector name: objectAtIndex: Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libobjc.A.dylib 0x938810ab objc_msgSend + 27 1 com.apple.AppKit 0x9184a305 -[NSTableView _dataSourceValueForColumn:row:] + 69 2 com.apple.AppKit 0x9194e127 -[NSTableView preparedCellAtColumn:row:] + 385 3 com.apple.AppKit 0x917efc91 -[NSTableView _dirtyVisibleCellsForKeyStateChange] + 878 What do you have set as the dataSource for the table? Is it still valid when the window owning the table becomes key? Is it owned by some object that might be in a weak property instead of strong? (Although you would probably see that right away when you debugged it.) Have you run static analysis on the project? Have you turned on Scribble, Guard Edges, and Guard Malloc in your scheme while debugging? Some of those can sometimes help force bugs to the surface. -- Steve Mills Drummer, Mac geek On 13/03/15 15:46, Peter Hudson wrote: Any comments or suggestions gratefully received ! Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libobjc.A.dylib 0x938810ab objc_msgSend + 27 1 com.apple.AppKit 0x9184a305 -[NSTableView _dataSourceValueForColumn:row:] + 69 2 com.apple.AppKit 0x9194e127 -[NSTableView preparedCellAtColumn:row:] + 385 3 com.apple.AppKit 0x917efc91 -[NSTableView _dirtyVisibleCellsForKeyStateChange] + 878 4 com.apple.AppKit 0x917ef6de -[NSTableView _windowChangedKeyState] + 323 This looks like a table's delegate or datasource has been disposed off while the table still uses it. Make sure to set table delegates/datasources to nil when the object being used as delegate/datasource is deallocated. Regards Markus -- ___ 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: Weird crashes on Yosemite
We had something like that recently on iOS where the delegate was disposed of and then on a timer call up to a minute later, one of its method calls was invoked resulting in an NSZombie related assertion coming up. What was the assertion thrown? Sent from my iPad. Please pardon typos. On Mar 13, 2015, at 10:55 AM, Markus Spoettl ms_li...@shiftoption.com wrote: On 13/03/15 15:46, Peter Hudson wrote: Any comments or suggestions gratefully received ! Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libobjc.A.dylib 0x938810ab objc_msgSend + 27 1 com.apple.AppKit 0x9184a305 -[NSTableView _dataSourceValueForColumn:row:] + 69 2 com.apple.AppKit 0x9194e127 -[NSTableView preparedCellAtColumn:row:] + 385 3 com.apple.AppKit 0x917efc91 -[NSTableView _dirtyVisibleCellsForKeyStateChange] + 878 4 com.apple.AppKit 0x917ef6de -[NSTableView _windowChangedKeyState] + 323 This looks like a table's delegate or datasource has been disposed off while the table still uses it. Make sure to set table delegates/datasources to nil when the object being used as delegate/datasource is deallocated. Regards Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com This email sent to z...@mac.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: setting table view rows and columns?
On Mar 13, 2015, at 1:29 AM, Steve Mills sjmi...@mac.com wrote: On Mar 13, 2015, at 02:18:00, Patrick J. Collins patr...@collinatorstudios.com wrote: The inspector shows the text set under 'Title', yet when I build, there is no text.. it's all blank.. Quite frustrating. You're sure you have an NSTableColumn selected, not Table View Cell that's in the column? Both have a Title field in the inspector. Also make sure that that headers is checked in the table view attributes inspector, or the headers won't be exposed to set in the first place. HTH, Keary Suska Esoteritech, Inc. Demystifying technology for your home or business ___ 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: setting table view rows and columns?
Also make sure that that headers is checked in the table view attributes inspector, or the headers won't be exposed to set in the first place. aargh! Totally missed that checkbox, and yeah that was my problem!!! thanks! Patrick J. Collins http://collinatorstudios.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
