Re: assertion failure

[Alex Zavatone]

> On Apr 8, 2018, at 1:58 PM, Alex Zavatone  wrote:
> 
> Do you mind putting the program up on Github or something similar so any of 
> us can take a look?
> 
> Do you check for existence of the file before deleting, or check its 
> properties to see if it is deletable?  I don’t know if this is required or 
> not, just submitting these as an option.
> 
> Cheers.
> 
> Alex Zavatone

Apologies.  I misread the second half of Steve’s reply and thought that applied 
to the actual problem mentioned, trying to make a utility window fullscreen.  

Happy Sunday.  

Alex Zavatone
___

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: assertion failure

[Alex Zavatone]

Do you mind putting the program up on Github or something similar so any of us 
can take a look?

Do you check for existence of the file before deleting, or check its properties 
to see if it is deletable?  I don’t know if this is required or not, just 
submitting these as an option.

Cheers.

Alex Zavatone

> On Apr 7, 2018, at 5:06 PM, Steve Christensen <puns...@mac.com> wrote:
> 
> It's not uncommon to have a method throw an exception when you make a 
> programming error so that you get immediate feedback. Not knowing offhand 
> which method(s) were called, my guess would be that they're designed to 
> always succeed if you specify the correct parameter values, so the assertion 
> is letting you know that your parameters aren't correct.
> 
> It's not like the case where, for example, you're trying to delete a file 
> that may or may not be there. In general usage either of those cases is just 
> as valid so the file system reports the error, if any, and lets your app 
> decide what to do.
> 
> 
>> On Apr 7, 2018, at 1:18 PM, Alan Snyder <applemail832...@cbfiddle.com> wrote:
>> 
>> I understand that my program is doing it wrong. But is it normal to have an 
>> assertion failure, rather than an error return?
>> 
>> 
>>> On Apr 7, 2018, at 12:04 PM, Rob Petrovec <petr...@mac.com> wrote:
>>> 
>>> It’s saying that you are doing it wrong.  Utility windows cannot go full 
>>> screen.  You have yours set to go full screen.  It shouldn’t be.
>>> 
>>> —Rob
>>> 
>>> 
>>>> On Apr 7, 2018, at 10:24 AM, Alan Snyder <applemail832...@cbfiddle.com> 
>>>> wrote:
>>>> 
>>>> I am getting an assertion failure notice on the console when running a 
>>>> small test program:
>>>> 
>>>> Assertion failure in -[AWTWindow_Panel _validateCollectionBehavior:], 
>>>> /Library/Caches/com.apple.xbs/Sources/AppKit/AppKit-1504.83.101/AppKit.subproj/NSWindow.m:14741
>>>> 
>>>> (This message is on 10.12.6, the details are different on 10.13.)
>>>> 
>>>> When run under Xcode, there is more information: utility panels cannot be 
>>>> fullscreen primary
>>>> 
>>>> My question—does this represent a bug in AppKit that I should report, or 
>>>> is it trying to help me by explaining that my program provided an 
>>>> unsupported set of style bits when creating a window?
>>>> 
>>>> Alan
> 
> ___
> 
> 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: assertion failure

[Steve Christensen]

It's not uncommon to have a method throw an exception when you make a 
programming error so that you get immediate feedback. Not knowing offhand which 
method(s) were called, my guess would be that they're designed to always 
succeed if you specify the correct parameter values, so the assertion is 
letting you know that your parameters aren't correct.

It's not like the case where, for example, you're trying to delete a file that 
may or may not be there. In general usage either of those cases is just as 
valid so the file system reports the error, if any, and lets your app decide 
what to do.


> On Apr 7, 2018, at 1:18 PM, Alan Snyder <applemail832...@cbfiddle.com> wrote:
> 
> I understand that my program is doing it wrong. But is it normal to have an 
> assertion failure, rather than an error return?
> 
> 
>> On Apr 7, 2018, at 12:04 PM, Rob Petrovec <petr...@mac.com> wrote:
>> 
>> It’s saying that you are doing it wrong.  Utility windows cannot go full 
>> screen.  You have yours set to go full screen.  It shouldn’t be.
>> 
>> —Rob
>> 
>> 
>>> On Apr 7, 2018, at 10:24 AM, Alan Snyder <applemail832...@cbfiddle.com> 
>>> wrote:
>>> 
>>> I am getting an assertion failure notice on the console when running a 
>>> small test program:
>>> 
>>> Assertion failure in -[AWTWindow_Panel _validateCollectionBehavior:], 
>>> /Library/Caches/com.apple.xbs/Sources/AppKit/AppKit-1504.83.101/AppKit.subproj/NSWindow.m:14741
>>> 
>>> (This message is on 10.12.6, the details are different on 10.13.)
>>> 
>>> When run under Xcode, there is more information: utility panels cannot be 
>>> fullscreen primary
>>> 
>>> My question—does this represent a bug in AppKit that I should report, or is 
>>> it trying to help me by explaining that my program provided an unsupported 
>>> set of style bits when creating a window?
>>> 
>>> Alan

___

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: assertion failure

[Alan Snyder]

I understand that my program is doing it wrong. But is it normal to have an 
assertion failure, rather than an error return?



> On Apr 7, 2018, at 12:04 PM, Rob Petrovec <petr...@mac.com> wrote:
> 
> It’s saying that you are doing it wrong.  Utility windows cannot go full 
> screen.  You have yours set to go full screen.  It shouldn’t be.
> 
> —Rob
> 
> 
>> On Apr 7, 2018, at 10:24 AM, Alan Snyder <applemail832...@cbfiddle.com> 
>> wrote:
>> 
>> I am getting an assertion failure notice on the console when running a small 
>> test program:
>> 
>> Assertion failure in -[AWTWindow_Panel _validateCollectionBehavior:], 
>> /Library/Caches/com.apple.xbs/Sources/AppKit/AppKit-1504.83.101/AppKit.subproj/NSWindow.m:14741
>> 
>> (This message is on 10.12.6, the details are different on 10.13.)
>> 
>> When run under Xcode, there is more information: utility panels cannot be 
>> fullscreen primary
>> 
>> My question—does this represent a bug in AppKit that I should report, or is 
>> it trying to help me by explaining that my program provided an unsupported 
>> set of style bits when creating a window?
>> 
>> Alan
>> 
>> ___
>> 
>> 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/petrock%40mac.com
>> 
>> This email sent to petr...@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: assertion failure

[Rob Petrovec]

It’s saying that you are doing it wrong.  Utility windows cannot go full 
screen.  You have yours set to go full screen.  It shouldn’t be.

—Rob


> On Apr 7, 2018, at 10:24 AM, Alan Snyder <applemail832...@cbfiddle.com> wrote:
> 
> I am getting an assertion failure notice on the console when running a small 
> test program:
> 
> Assertion failure in -[AWTWindow_Panel _validateCollectionBehavior:], 
> /Library/Caches/com.apple.xbs/Sources/AppKit/AppKit-1504.83.101/AppKit.subproj/NSWindow.m:14741
> 
> (This message is on 10.12.6, the details are different on 10.13.)
> 
> When run under Xcode, there is more information: utility panels cannot be 
> fullscreen primary
> 
> My question—does this represent a bug in AppKit that I should report, or is 
> it trying to help me by explaining that my program provided an unsupported 
> set of style bits when creating a window?
> 
>  Alan
> 
> ___
> 
> 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/petrock%40mac.com
> 
> This email sent to petr...@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

assertion failure

[Alan Snyder]

I am getting an assertion failure notice on the console when running a small 
test program:

Assertion failure in -[AWTWindow_Panel _validateCollectionBehavior:], 
/Library/Caches/com.apple.xbs/Sources/AppKit/AppKit-1504.83.101/AppKit.subproj/NSWindow.m:14741

(This message is on 10.12.6, the details are different on 10.13.)

When run under Xcode, there is more information: utility panels cannot be 
fullscreen primary

My question—does this represent a bug in AppKit that I should report, or is it 
trying to help me by explaining that my program provided an unsupported set of 
style bits when creating a window?

  Alan

___

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

Getting Assertion failure in -[UITableView _endCellAnimationsWithContext:]

[Rick Mann]

(Let's try this with a subject!)

I'm getting *** Assertion failure in -[UITableView 
_endCellAnimationsWithContext:],  but I'm not getting the message like this 
that you typically get (there's no message indicating what went wrong):

'Invalid update: invalid number of rows in section 0.  The number of rows 
contained in an existing section after the update (1) must be equal to the 
number of rows contained in that section before the update (1), plus or minus 
the number of rows inserted or deleted from that section (1 inserted, 0 
deleted).'

Every time a new thing is added to the list (as a result of scanning for BLE 
peripherals), I'm calling beginUpdate, doing an insert, add to the backing 
array, optionally a deletion (only on the first insert to get rid of a none 
found cell), and endUpdate. The assertion fires on the -endUpdate call at the 
fifth insert.

So, this works most of the time. I can't figure out what's going on. Checking 
all the counts they seem fine.

Any ideas what else may be going on?

-- 
Rick





signature.asc
Description: Message signed with OpenPGP using GPGMail
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: assertion failure from NSScrollView

[James Walker]

On 6/12/2013 6:51 PM, James Walker wrote:

In Lion 10.7.4, if the General preference pane has set Show scroll
bars to Automatically based on input device, then when my window
appears I see the following mess in the log.  The other two preference
alternatives don't cause this.  Any idea what's going on?  (The input
device is a mouse, by the way.)


Never mind, I found the problem.  It was code equivalent to

[[NSScrollView new] initWithFrame: someRect]

thus initializing the object twice.

--
  James W. Walker, Innoventive Software LLC
  http://www.frameforge3d.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

assertion failure from NSScrollView

[James Walker]

In Lion 10.7.4, if the General preference pane has set Show scroll 
bars to Automatically based on input device, then when my window 
appears I see the following mess in the log.  The other two preference 
alternatives don't cause this.  Any idea what's going on?  (The input 
device is a mouse, by the way.)



2013-06-12 18:43:26.049 XEditorDemo[2074:903] *** Assertion failure in 
-[NSScrollView 
scrollerImpPair:updateScrollerStyleForNewRecommendedScrollerStyle:], 
/SourceCache/AppKit/AppKit-1138.51/AppKit.subproj/NSScrollView.m:4344
2013-06-12 18:43:31.549 CrossPlatformRTFEditorDemo[2074:903] Invalid 
parameter not satisfying: scrollerImpPair == SCROLLER_IMP_PAIR

2013-06-12 18:43:31.553 CrossPlatformRTFEditorDemo[2074:903] (
0   CoreFoundation  0x9772ea67 __raiseError + 231
	1   libobjc.A.dylib 0x995a3149 objc_exception_throw 
+ 155
	2   CoreFoundation  0x97696289 +[NSException 
raise:format:arguments:] + 137
	3   Foundation  0x9cc34233 -[NSAssertionHandler 
handleFailureInMethod:object:file:lineNumber:description:] + 116
	4   AppKit  0x915f1d2e 
-[NSScrollView(NSPrivate) 
scrollerImpPair:updateScrollerStyleForNewRecommendedScrollerStyle:] + 152
	5   AppKit  0x9170a3a0 +[NSScrollerImpPair 
_updateAllScrollerImpPairsForNewRecommendedScrollerStyle:] + 446
	6   AppKit  0x9170a131 +[NSScrollerImpPair 
_scrollerStyleRecommendationChanged:] + 159
	7   Foundation  0x9cb70df1 
__-[NSNotificationCenter 
addObserver:selector:name:object:]_block_invoke_1 + 49
	8   CoreFoundation  0x9766e903 
___CFXNotificationPost_block_invoke_1 + 275
	9   CoreFoundation  0x97639688 _CFXNotificationPost 
+ 2776
	10  Foundation  0x9cb5bfde 
-[NSNotificationCenter postNotificationName:object:userInfo:] + 92
	11  AppKit  0x9101bf9b 
-[_NSScrollerStyleRecommender setRecommendedScrollerStyleAndNotify:] + 260
	12  AppKit  0x9101be92 
__-[_NSScrollerStyleRecommender 
scrollerStyleRecommendationUpdateTimerFired:]_block_invoke_1 + 43
	13  AppKit  0x9101be62 
___NSDetectScrollDevicesThenInvokeOnMainQueue_block_invoke_3 + 32
	14  libdispatch.dylib   0x974a3fbd 
_dispatch_call_block_and_release + 15
	15  libdispatch.dylib   0x974a5f4d 
_dispatch_main_queue_callback_4CF + 260

16  CoreFoundation  0x97624d43 __CFRunLoopRun + 2003
	17  CoreFoundation  0x976241dc CFRunLoopRunSpecific 
+ 332

18  CoreFoundation  0x97624088 CFRunLoopRunInMode + 
120
	19  HIToolbox   0x92b20543 
RunCurrentEventLoopInMode + 318
	20  HIToolbox   0x92b278ab 
ReceiveNextEventCommon + 381
	21  HIToolbox   0x92b2771a 
BlockUntilNextEventMatchingListInMode + 88

22  AppKit  0x90dd1ee8 _DPSNextEvent + 678
	23  AppKit  0x90dd1752 -[NSApplication 
nextEventMatchingMask:untilDate:inMode:dequeue:] + 113
	24  AppKit  0x90dcdac1 -[NSApplication run] 
+ 911


--
  James W. Walker, Innoventive Software LLC
  http://www.frameforge3d.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

NSTextFieldCell assertion failure messages?

[Erik Stainsby]

Can anyone tell me what I ought to be doing in response to the following 
message?

 *** Assertion failure in -[NSTextFieldCell 
_objectValue:forString:errorDescription:], 
/SourceCache/AppKit/AppKit-1187.34/AppKit.subproj/NSCell.m:1532


This is cropping up in a table delegate/datasource when I bind: the textField 
in an NSTableViewCell to my model object.
Each model object has three fields and any of them may be empty. So in my 
tableView:viewForColumn:row: method I set each of the textFields' stringValue: 
to @  before binding it to it's object.


- (NSView*) tableView:(NSTableView *)tableView 
viewForTableColumn:(NSTableColumn *)tableColumn row:(NSInteger)row {

RSPerson * person = (RSPerson*)[self.personAC.content objectAtIndex:row];
NSTableCellView * cellView = [tableView makeViewWithIdentifier:[NSString 
stringWithFormat:@%@Cell,[tableColumn identifier]] owner:self];
cellView.textField.stringValue = @ ;
[cellView.textField bind:@stringValue toObject:person 
withKeyPath:[tableColumn identifier] options:nil];
return cellView;
}


Any advice appreciated.  


Erik Stainsby
erik.stain...@roaringsky.ca


___

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: NSTextFieldCell assertion failure messages?

[Quincey Morris]

On Oct 7, 2012, at 14:18 , Erik Stainsby erik.stain...@roaringsky.ca wrote:

cellView.textField.stringValue = @ ;
[cellView.textField bind:@stringValue toObject:person 
 withKeyPath:[tableColumn identifier] options:nil];

There are several wrong or code-smelly things here:

-- Why on earth set the string to a space? It's going to make the UI behave 
oddly for users. If you don't want a string property to be nil, set it to @.

-- There's no point in setting a property if the next thing you do is bind 
something that changes the same property. You've done the analog of 'x = 0; x = 
1;' here.

-- Text fields don't have a stringValue binding, they only have a value 
binding:


https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/CocoaBindingsRef/BindingsText/NSTextField.html


___

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: Assertion failure in -[MPMoviePlayerControllerNew _moviePlayerDidBecomeActiveNotification:]

[Matt Neuburg]

On Sun, 13 Mar 2011 15:14:53 -0700, Steve Christensen puns...@mac.com said:
On Mar 13, 2011, at 11:05 AM, Matt Neuburg wrote:

 On Tue, 08 Mar 2011 17:01:33 -0800, Steve Christensen puns...@mac.com said:
 The setup has a MPMoviePlayerController instance that is playing a local 
 audio file. There is also a UIWebView whose HTML contains an audio tag. 
 When the play control is tapped, I see a 
 MPMoviePlayerPlaybackDidFinishNotification notification with a reason of 
 MPMovieFinishReasonPlaybackEnded, then gdb shows the assertion failure and 
 exception and dumps the backtrace (below).
 
 What was the outcome on this? Thx - m.

Well, I'm still not sure of the exact why for the assertion, but I figured 
out what I was doing that it didn't like.

My MPMoviePlayerPlaybackDidFinishNotification handler is designed to queue up 
another audio file to play after the current one finishes. I NSLog'd the 
player initialization and all the notification handlers so I could watch the 
process more in realtime, and found that the next audio file was loaded and 
then very soon after got a MPMoviePlayerPlaybackDidFinishNotification. A bit 
after that is when the assertion failure and exception come along.

After playing with it for a bit, I found that the player's loadState property 
is set to (MPMovieLoadStatePlayable | MPMovieLoadStatePlaythroughOK) when 
playback finishes normally or MPMovieLoadStateUnknown when it's stopped 
because another player instance has grabbed control. I've added a test that 
prevents the queueing if the loadState is MPMovieLoadStateUnknown and that 
seems to work just fine.

I may have missed something in the docs that talks about this situation, but 
it's also probably true that I'm not using the player class in the most 
standard manner.

Thanks, Steve - mostly I just wanted to make sure that this wasn't something I 
was likely to encounter, and you've made clear that it isn't, since the cause 
of the issue was really the automatic queuing behavior. This explains 
perfectly how you could be getting a didBecomeActive notification right after 
playback finishes: *you* were making the MPMoviePlayerController active once 
again.

I guess I'm not surprised that the MPMoviePlayerController would not like your 
loading up an audio file while the UIWebView is already playing an audio file, 
since there is this rule that There Can Be Only One - for example, trying to 
put two MPMoviePlayerController views into your app and playing them both 
simultaneously won't work either. This is part of the price we pay for the 
simplicity of these ways of playing sound.

Glad you got it straightened out - m.

--
matt neuburg, phd = m...@tidbits.com, http://www.apeth.net/matt/
A fool + a tool + an autorelease pool = cool!
Programming iOS 4!
http://www.apeth.net/matt/default.html#iosbook___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Assertion failure in -[MPMoviePlayerControllerNew _moviePlayerDidBecomeActiveNotification:]

[Matt Neuburg]

On Tue, 08 Mar 2011 17:01:33 -0800, Steve Christensen puns...@mac.com said:
The setup has a MPMoviePlayerController instance that is playing a local audio 
file. There is also a UIWebView whose HTML contains an audio tag. When the 
play control is tapped, I see a MPMoviePlayerPlaybackDidFinishNotification 
notification with a reason of MPMovieFinishReasonPlaybackEnded, then gdb shows 
the assertion failure and exception and dumps the backtrace (below).

What was the outcome on this? Thx - m.

--
matt neuburg, phd = m...@tidbits.com, http://www.apeth.net/matt/
A fool + a tool + an autorelease pool = cool!
Programming iOS 4!
http://www.apeth.net/matt/default.html#iosbook___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Assertion failure in -[MPMoviePlayerControllerNew _moviePlayerDidBecomeActiveNotification:]

[Steve Christensen]

On Mar 13, 2011, at 11:05 AM, Matt Neuburg wrote:

 On Tue, 08 Mar 2011 17:01:33 -0800, Steve Christensen puns...@mac.com said:
 The setup has a MPMoviePlayerController instance that is playing a local 
 audio file. There is also a UIWebView whose HTML contains an audio tag. 
 When the play control is tapped, I see a 
 MPMoviePlayerPlaybackDidFinishNotification notification with a reason of 
 MPMovieFinishReasonPlaybackEnded, then gdb shows the assertion failure and 
 exception and dumps the backtrace (below).
 
 What was the outcome on this? Thx - m.

Well, I'm still not sure of the exact why for the assertion, but I figured 
out what I was doing that it didn't like.

My MPMoviePlayerPlaybackDidFinishNotification handler is designed to queue up 
another audio file to play after the current one finishes. I NSLog'd the player 
initialization and all the notification handlers so I could watch the process 
more in realtime, and found that the next audio file was loaded and then very 
soon after got a MPMoviePlayerPlaybackDidFinishNotification. A bit after that 
is when the assertion failure and exception come along.

After playing with it for a bit, I found that the player's loadState property 
is set to (MPMovieLoadStatePlayable | MPMovieLoadStatePlaythroughOK) when 
playback finishes normally or MPMovieLoadStateUnknown when it's stopped because 
another player instance has grabbed control. I've added a test that prevents 
the queueing if the loadState is MPMovieLoadStateUnknown and that seems to work 
just fine.

I may have missed something in the docs that talks about this situation, but 
it's also probably true that I'm not using the player class in the most 
standard manner.

steve

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Assertion failure in -[MPMoviePlayerControllerNew _moviePlayerDidBecomeActiveNotification:]

[Dave Camp]

I saw that assertion yesterday in a bit of code that was accidentally calling a 
MPMoviePlayerController method from a secondary thread.

Dave

On Mar 8, 2011, at 5:01 PM, Steve Christensen wrote:

 I'm seeing the above assertion in an app running on iOS 4.2.1. It then throws 
 an NSInternalInconsistencyException with the reason: movie player 
 MPMoviePlayerControllerNew: 0x446fbe0 has wrong activation state (1).
 
 The setup has a MPMoviePlayerController instance that is playing a local 
 audio file. There is also a UIWebView whose HTML contains an audio tag. 
 When the play control is tapped, I see a 
 MPMoviePlayerPlaybackDidFinishNotification notification with a reason of 
 MPMovieFinishReasonPlaybackEnded, then gdb shows the assertion failure and 
 exception and dumps the backtrace (below).
 
 If I start playing the HTML's audio then start the MPMoviePlayerController's 
 audio, the HTML's audio fades out and the MPMoviePlayerController's plays, so 
 there's probably some subtle difference I'm missing. Any ideas what I might 
 be doing wrong or what to look at? Everything is working great except when it 
 comes time for dueling audio.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Assertion failure in -[MPMoviePlayerControllerNew _moviePlayerDidBecomeActiveNotification:]

[Steve Christensen]

I'm seeing the above assertion in an app running on iOS 4.2.1. It then throws 
an NSInternalInconsistencyException with the reason: movie player 
MPMoviePlayerControllerNew: 0x446fbe0 has wrong activation state (1).

The setup has a MPMoviePlayerController instance that is playing a local audio 
file. There is also a UIWebView whose HTML contains an audio tag. When the 
play control is tapped, I see a MPMoviePlayerPlaybackDidFinishNotification 
notification with a reason of MPMovieFinishReasonPlaybackEnded, then gdb shows 
the assertion failure and exception and dumps the backtrace (below).

If I start playing the HTML's audio then start the MPMoviePlayerController's 
audio, the HTML's audio fades out and the MPMoviePlayerController's plays, so 
there's probably some subtle difference I'm missing. Any ideas what I might be 
doing wrong or what to look at? Everything is working great except when it 
comes time for dueling audio.

steve

-
0   CoreFoundation  0x314d0987 __exceptionPreprocess + 114
1   libobjc.A.dylib 0x319a149d objc_exception_throw + 24
2   CoreFoundation  0x314d07c9 +[NSException raise:format:arguments:] + 68
3   Foundation  0x31d1629f -[NSAssertionHandler 
handleFailureInMethod:object:file:lineNumber:description:] + 62
4   MediaPlayer 0x360b1571 -[MPMoviePlayerControllerNew 
_moviePlayerDidBecomeActiveNotification:] + 124
5   Foundation  0x31cd8623 _nsnote_callback + 142
6   CoreFoundation  0x31457123 __CFXNotificationPost_old + 402
7   CoreFoundation  0x31456dc3 _CFXNotificationPostNotification + 118
8   Foundation  0x31cc7d23 -[NSNotificationCenter 
postNotificationName:object:userInfo:] + 70
9   MediaPlayer 0x360b0e09 -[MPMoviePlayerControllerNew 
_postNotificationName:object:userInfo:] + 72
10  MediaPlayer 0x360b0e41 -[MPMoviePlayerControllerNew 
_postNotificationName:object:] + 24
11  MediaPlayer 0x360b0fc1 -[MPMoviePlayerControllerNew _resignActive] + 52
12  MediaPlayer 0x360b2fb7 -[MPMoviePlayerController _resignActive] + 66
13  CoreFoundation  0x31473fc7 -[NSObject(NSObject) performSelector:] + 18
14  CoreFoundation  0x3147cd51 -[NSArray makeObjectsPerformSelector:] + 388
15  MediaPlayer 0x360b44a1 +[MPMoviePlayerController 
allInstancesResignActive] + 32
16  MediaPlayer 0x360bc143 -[UIMoviePlayerController _ensureActive] + 62
17  MediaPlayer 0x360b8d17 -[UIMoviePlayerController 
videoController:tappedButtonPart:] + 18
18  MediaPlayer 0x36115cfb -[MPInlineVideoViewController 
transportControls:tappedButtonPart:] + 78
19  MediaPlayer 0x360e4f75 -[MPTransportControls _handleTapForPart:] + 112
20  MediaPlayer 0x360e54ad -[MPTransportControls buttonUp:] + 60
21  CoreFoundation  0x31477fed -[NSObject(NSObject) 
performSelector:withObject:withObject:] + 24
22  UIKit   0x338c14ad -[UIApplication sendAction:to:from:forEvent:] + 
84
23  UIKit   0x338c144d -[UIApplication 
sendAction:toTarget:fromSender:forEvent:] + 32
24  UIKit   0x338c141f -[UIControl sendAction:to:forEvent:] + 38
25  UIKit   0x338c1171 -[UIControl(Internal) 
_sendActionsForEvents:withEvent:] + 356
26  UIKit   0x338c19cf -[UIControl touchesEnded:withEvent:] + 342
27  UIKit   0x338b7355 -[UIWindow _sendTouchesForEvent:] + 368
28  UIKit   0x338b6ccf -[UIWindow sendEvent:] + 262

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSOutlineView assertion failure on collapse

[Corbin Dunn]

Hi Roland,
Can you reliable reproduce this problem? If so, can you please log a  
bug, including your test application (or a link to download it). Or,  
ideally, if you have source code that can be compiled that makes  
things even easier to debug.


-corbin

On Dec 15, 2008, at 11:08 AM, Roland Rabien wrote:

I'm having an NSOutlineView Assertion Failure on collapse if the  
selected

item is a child (or child of child, etc) of the item that is being
collapsed. Has anyone else had this problem? I've searched the list  
all the
related posts seem to indicate threading is the cause, but my  
application
isn't using any threads. I'm using XCode 3.1 and targeting 10.5  
(Intel). I
never call reloadData on my NSOutLineView, so it's data should be  
constant.

Any ideas?

 Assertion failure in -[NSOutlineView
_expandItemEntry:expandChildren:startLevel:](),
/SourceCache/AppKit/AppKit-949.35/TableView.subproj/NSOutlineView.m: 
1003*



#0 0x92a42c66 in -[NSException raise]

#1 0x9259ef22 in -[NSOutlineView collapseItem:collapseChildren:]

#2 0x92306c9a in -[NSOutlineView
_doUserExpandOrCollapseOfItem:isExpand:optionKeyWasDown:]

#3 0x9230679e in -[NSOutlineView  
mouseTracker:didStopTrackingWithEvent:]


#4 0x923065ce in -[NSMouseTracker stopTrackingWithEvent:]

#5 0x92278d03 in -[NSMouseTracker trackWithEvent:inView:withDelegate:]

#6 0x921bdb54 in -[NSOutlineView mouseDown:]

#7 0x9216476b in -[NSWindow sendEvent:]

#8 0x92131311 in -[NSApplication sendEvent:]

#9 0x9208ed0f in -[NSApplication run]

#10 0x9205bf14 in NSApplicationMain

#11 0x1c70 in main at main.m:13
___


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSOutlineView assertion failure on collapse

[Roland Rabien]

In building a small app that reproduces the problem I found the cause of the
assertion. It's caused by me being stupid.
The following code reproduces the assertion:

- (void)outlineViewItemWillCollapse:(NSNotification *)notification
{
id itm = [[notification userInfo] objectForKey:@NSObject];
[tree expandItem:itm];
}

Is this a bug? Or is the assertion valid.

What my code was supposed to do is select the item being collapsed if a
child was selected. I used my standard select item  function which selects
an item an expands it, causing the assertion.

Thanks,
Roland

On Tue, Dec 16, 2008 at 9:36 AM, Corbin Dunn corb...@apple.com wrote:

 Hi Roland,
 Can you reliable reproduce this problem? If so, can you please log a bug,
 including your test application (or a link to download it). Or, ideally, if
 you have source code that can be compiled that makes things even easier to
 debug.

 -corbin


 On Dec 15, 2008, at 11:08 AM, Roland Rabien wrote:

  I'm having an NSOutlineView Assertion Failure on collapse if the selected
 item is a child (or child of child, etc) of the item that is being
 collapsed. Has anyone else had this problem? I've searched the list all
 the
 related posts seem to indicate threading is the cause, but my application
 isn't using any threads. I'm using XCode 3.1 and targeting 10.5 (Intel). I
 never call reloadData on my NSOutLineView, so it's data should be
 constant.
 Any ideas?

  Assertion failure in -[NSOutlineView
 _expandItemEntry:expandChildren:startLevel:](),
 /SourceCache/AppKit/AppKit-949.35/TableView.subproj/NSOutlineView.m:1003*


 #0 0x92a42c66 in -[NSException raise]

 #1 0x9259ef22 in -[NSOutlineView collapseItem:collapseChildren:]

 #2 0x92306c9a in -[NSOutlineView
 _doUserExpandOrCollapseOfItem:isExpand:optionKeyWasDown:]

 #3 0x9230679e in -[NSOutlineView mouseTracker:didStopTrackingWithEvent:]

 #4 0x923065ce in -[NSMouseTracker stopTrackingWithEvent:]

 #5 0x92278d03 in -[NSMouseTracker trackWithEvent:inView:withDelegate:]

 #6 0x921bdb54 in -[NSOutlineView mouseDown:]

 #7 0x9216476b in -[NSWindow sendEvent:]

 #8 0x92131311 in -[NSApplication sendEvent:]

 #9 0x9208ed0f in -[NSApplication run]

 #10 0x9205bf14 in NSApplicationMain

 #11 0x1c70 in main at main.m:13
 ___



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSOutlineView assertion failure on collapse

[Corbin Dunn]

On Dec 16, 2008, at 3:54 PM, Roland Rabien wrote:

In building a small app that reproduces the problem I found the  
cause of the assertion. It's caused by me being stupid.


The following code reproduces the assertion:

- (void)outlineViewItemWillCollapse:(NSNotification *)notification
{
id itm = [[notification userInfo] objectForKey:@NSObject];
[tree expandItem:itm];
}

Is this a bug? Or is the assertion valid.


I think the assertion is valid, but it may be possible for us to  
provide a better assertion. Something along the lines of expanding  
item X while it was being collapsed. If you do have a test case,  
please log it into a bug, so we can either add a better assertion, or  
document the behavior.


Thank you for taking the time to simplify the problem.
-corbin




What my code was supposed to do is select the item being collapsed  
if a child was selected. I used my standard select item  function  
which selects an item an expands it, causing the assertion.


Thanks,
Roland


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

NSOutlineView assertion failure on collapse

[Roland Rabien]

I'm having an NSOutlineView Assertion Failure on collapse if the selected
item is a child (or child of child, etc) of the item that is being
collapsed. Has anyone else had this problem? I've searched the list all the
related posts seem to indicate threading is the cause, but my application
isn't using any threads. I'm using XCode 3.1 and targeting 10.5 (Intel). I
never call reloadData on my NSOutLineView, so it's data should be constant.
Any ideas?

 Assertion failure in -[NSOutlineView
_expandItemEntry:expandChildren:startLevel:](),
/SourceCache/AppKit/AppKit-949.35/TableView.subproj/NSOutlineView.m:1003*


#0 0x92a42c66 in -[NSException raise]

#1 0x9259ef22 in -[NSOutlineView collapseItem:collapseChildren:]

#2 0x92306c9a in -[NSOutlineView
_doUserExpandOrCollapseOfItem:isExpand:optionKeyWasDown:]

#3 0x9230679e in -[NSOutlineView mouseTracker:didStopTrackingWithEvent:]

#4 0x923065ce in -[NSMouseTracker stopTrackingWithEvent:]

#5 0x92278d03 in -[NSMouseTracker trackWithEvent:inView:withDelegate:]

#6 0x921bdb54 in -[NSOutlineView mouseDown:]

#7 0x9216476b in -[NSWindow sendEvent:]

#8 0x92131311 in -[NSApplication sendEvent:]

#9 0x9208ed0f in -[NSApplication run]

#10 0x9205bf14 in NSApplicationMain

#11 0x1c70 in main at main.m:13
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

assertion failure in AppKit

[Torsten Curdt]

Hey guys,

Some of my users are reporting an exception

 NSInternalInconsistencyException
 lockFocus sent to a view whose window is deferred and does not yet  
have a corresponding platform window


This is in the logs:

  *** Assertion failure in -[NSThemeFrame lockFocus], AppKit.subproj/ 
NSView.m:3248
 lockFocus sent to a view whose window is deferred and does not yet  
have a corresponding platform window


And I have absolutely no clue what this could be. The window has to be  
there. They pressed a button to start the processing. Any pointers?


In case someone wants to see the full source:

 git clone git://vafer.org/uif2iso4mac.git

cheers
--
Torsten
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

NSOutlineView assertion failure on redraw .. ?

[Michael Hanna]

I have an NSTreeController bound to a data model:

[m_rulesDMTreeController bind:@contentArray
 toObject:rulesDM
  withKeyPath:@rules
  options:nil];

and an NSTableColumn(inside an nsoutlineview) bound to the tree
controller.arrangedObjects.Name keypath. Infrequently, but not always,
I will get an assertion error:

2008-07-02 14:13:19.387 Submit[390:10b] *** Assertion failure in
-[NSOutlineView _expandItemEntry:expandChildren:startLevel:](),
/SourceCache/AppKit/AppKit-949.33/TableView.subproj/NSOutlineView.m:1003
2008-07-02 14:13:19.388 Submit[390:10b] Invalid parameter not
satisfying: itemEntry-children == NULL

This occurred when I ran this code:

[cut]
//  make the cocoa bindings system be aware of the change
with -mutableArrayValueForKey

NSMutableArray* sourceChildren = [sourceParent
mutableArrayValueForKey:@children];
NSMutableArray* destinationChildren = [destinationParent
mutableArrayValueForKey:@children];

//  re-parent the group we're moving and do the move operation

[movedGroup setParentGuid:destinationParentGuid];

[self willChangeValueForKey:@rules];

[destinationChildren addObject:movedGroup];
[sourceChildren removeObject:movedGroup];

//  if the source parent has zero children, delete it from
m_elements

if( [sourceChildren count] == 0 )
{
[self deleteRule:sourceParent allRuleGroups:[self ruleGroups]];
}

[self didChangeValueForKey:@rules];
[cut]

I have an observer watching the rules data model and the assertion
error occurs before the data model gets changed.

This doesn't happen that frequently, but enough to be a concern. Any
suggestions why the outlineview is re-populating before the data model
changes(apparently)?

Failing any reasonable workaround, is there a way I can detect when
this assertion occurs so I can attempt a 'fallback' mechanism?

Michael
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Assertion failure in -[NSNextStepFrame lockFocus]

[Uli Kusterer]

Am 15.05.2008 um 11:24 schrieb Apparao Mulpuri:

2008-05-15 14:45:33.469 MyCocoaApp[554:10b] NSExceptionHandler has
recorded the following exception:
NSInternalInconsistencyException -- -[NSNextStepFrame(0x12e0d0)



 The last time I got an internal inconsistency exception was when I  
was accidentally messing with views and windows from another thread  
than the main thread. That was what created the inconsistency that  
later caused this exception on a completely unrelated thread.


 You wouldn't perhaps be messing with the GUI from the wrong thread  
by accident?


Cheers,
-- Uli Kusterer
The Witnesses of TeachText are everywhere...
http://www.zathras.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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Assertion failure in -[NSNextStepFrame lockFocus]

[Apparao Mulpuri]

Here is the Stacktrace:

2008-05-15 14:45:33.469 MyCocoaApp[554:10b] NSExceptionHandler has
recorded the following exception:
NSInternalInconsistencyException -- -[NSNextStepFrame(0x12e0d0)
lockFocus] failed with window=0x145b30, windowNumber=340, [self
isHiddenOrHasHiddenAncestor]=0
Stack trace:  0x34dbc  0x9416676c  0x95df9e04  0x9112cde4  0x9569235c
0x956914c8  0x955e5498  0x955e52f8  0x95d8b018  0x95d8c1c8  0x92d823a8
 0x92d82134  0x92d8200c  0x955e33c0  0x955e2d88  0x955dca44
0x955ad448  0x251c  0x2220  0x1
2008-05-15 14:45:33.470 MyCocoaApp[554:10b]
-[NSNextStepFrame(0x12e0d0) lockFocus] failed with window=0x145b30,
windowNumber=340, [self isHiddenOrHasHiddenAncestor]=0
2008-05-15 14:45:33.508 MyCocoaApp[554:10b] *** Assertion failure in
-[NSNextStepFrame lockFocus],
/SourceCache/AppKit/AppKit-949.27/AppKit.subproj/NSView.m:4751


On Thu, May 15, 2008 at 10:01 AM, Jens Alfke [EMAIL PROTECTED] wrote:

 On 14 May '08, at 9:17 PM, Apparao Mulpuri wrote:

 ** Assertion failure in -[NSNextStepFrame lockFocus],
 /SourceCache/AppKit/AppKit-949.27/AppKit.subproj/NSView.m:4751
 May 14 17:37:39 apparao-power-mac-g5 MyCocoaApp[123]:
 -[NSNextStepFrame(0x143610) lockFocus] failed with window=0x142e60,
 windowNumber=62, [self isHiddenOrHasHiddenAncestor]

 What's the backtrace?
 Set a breakpoint at objc_exception_throw to find out.

 —Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Assertion failure in -[NSNextStepFrame lockFocus]

[Apparao Mulpuri]

Here is the complete stacktrace:

2008-05-15 15:58:53.730 MyCocoaApp[618:10b] *** Assertion failure in
-[NSNextStepFrame lockFocus],
/SourceCache/AppKit/AppKit-949.27/AppKit.subproj/NSView.m:4751
2008-05-15 15:58:53.737 MyCocoaApp[618:10b] NSExceptionHandler has
recorded the following exception:
NSInternalInconsistencyException -- -[NSNextStepFrame(0x146050)
lockFocus] failed with window=0x1457e0, windowNumber=230, [self
isHiddenOrHasHiddenAncestor]=0
Stack trace:  0x34dbc  0x9416676c  0x95df9e04  0x9112cde4  0x9569235c
0x956914c8  0x9568610c  0x956d0650  0x95809cdc  0x9587d248  0x956bb1fc
 0x47b4  0x9569f3bc  0x9573aabc  0x9573a7ec  0x9571bfac  0x92d58f6c
0x92d58104  0x92d750e4  0x92daafd4  0x92dd183c  0x92dd1728  0x92e239dc
 0x92e233b0  0x957f14a4  0x958257d4  0x95acfb74  0x95acf52c
0x9569da7c  0x9569c340  0x95792338  0x9566f79c  0x955dca6c  0x955ad448
 0x224c  0x1f50  0x1
NSExceptionHandlerExceptionRaiser (in ExceptionHandling)
objc_exception_throw (in libobjc.A.dylib)
+[NSException raise:format:] (in CoreFoundation)
-[NSAssertionHandler
handleFailureInMethod:object:file:lineNumber:description:] (in
Foundation)
-[NSView lockFocus] (in AppKit)
-[NSView _displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:]
(in AppKit)
-[NSWindow _setFrameCommon:display:stashSize:] (in AppKit)
-[NSMoveHelper _stopAnimation] (in AppKit)
-[NSMoveHelper _doAnimation] (in AppKit)
-[NSMoveHelper _resizeWindow:toFrame:display:] (in AppKit)
-[NSWindow setFrame:display:animate:] (in AppKit)
-[MyController changeGridType:] (in MyCocoaApp)
-[NSApplication sendAction:to:from:] (in AppKit)
-[NSMenu performActionForItemAtIndex:] (in AppKit)
-[NSCarbonMenuImpl performActionWithHighlightingForItemAtIndex:] (in AppKit)
AppKitMenuEventHandler (in AppKit)
DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*,
HandlerCallRec*) (in HIToolbox)
SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*,
HandlerCallRec*) (in HIToolbox)
SendEventToEventTarget (in HIToolbox)
SendHICommandEvent(unsigned long, HICommand const*, unsigned long,
unsigned long, unsigned char, OpaqueEventTargetRef*,
OpaqueEventTargetRef*, OpaqueEventRef**) (in HIToolbox)
SendMenuItemSelectedEvent (in HIToolbox)
FinishMenuSelection(MenuData*, MenuData*, MenuResult*, MenuResult*,
unsigned long, unsigned long, unsigned long, unsigned char) (in
HIToolbox)
PopUpMenuSelectCore(MenuData*, Point, double, Point, unsigned short,
unsigned int, Rect const*, unsigned short, unsigned long, Rect const*,
Rect const*, __CFString const*, OpaqueMenuRef**, unsigned short*) (in
HIToolbox)
_HandlePopUpMenuSelection7 (in HIToolbox)
_NSPopUpCarbonMenu3 (in AppKit)
-[NSCarbonMenuImpl
popUpMenu:atLocation:width:forView:withSelectedItem:withFont:withFlags:withOptions:]
(in AppKit)
+[NSStatusBarButtonCell popupStatusBarMenu:inRect:ofView:withEvent:] (in AppKit)
-[NSStatusBarButtonCell trackMouse:inRect:ofView:untilMouseUp:] (in AppKit)
-[NSControl mouseDown:] (in AppKit)
-[NSWindow sendEvent:] (in AppKit)
-[NSStatusBarWindow sendEvent:] (in AppKit)
-[NSApplication sendEvent:] (in AppKit)
-[NSApplication run] (in AppKit)
NSApplicationMain (in AppKit)
_start (in MyCocoaApp)
start (in MyCocoaApp)


On Thu, May 15, 2008 at 2:54 PM, Apparao Mulpuri
[EMAIL PROTECTED] wrote:
 Here is the Stacktrace:

 2008-05-15 14:45:33.469 MyCocoaApp[554:10b] NSExceptionHandler has
 recorded the following exception:
 NSInternalInconsistencyException -- -[NSNextStepFrame(0x12e0d0)
 lockFocus] failed with window=0x145b30, windowNumber=340, [self
 isHiddenOrHasHiddenAncestor]=0
 Stack trace:  0x34dbc  0x9416676c  0x95df9e04  0x9112cde4  0x9569235c
 0x956914c8  0x955e5498  0x955e52f8  0x95d8b018  0x95d8c1c8  0x92d823a8
  0x92d82134  0x92d8200c  0x955e33c0  0x955e2d88  0x955dca44
 0x955ad448  0x251c  0x2220  0x1
 2008-05-15 14:45:33.470 MyCocoaApp[554:10b]
 -[NSNextStepFrame(0x12e0d0) lockFocus] failed with window=0x145b30,
 windowNumber=340, [self isHiddenOrHasHiddenAncestor]=0
 2008-05-15 14:45:33.508 MyCocoaApp[554:10b] *** Assertion failure in
 -[NSNextStepFrame lockFocus],
 /SourceCache/AppKit/AppKit-949.27/AppKit.subproj/NSView.m:4751


 On Thu, May 15, 2008 at 10:01 AM, Jens Alfke [EMAIL PROTECTED] wrote:

 On 14 May '08, at 9:17 PM, Apparao Mulpuri wrote:

 ** Assertion failure in -[NSNextStepFrame lockFocus],
 /SourceCache/AppKit/AppKit-949.27/AppKit.subproj/NSView.m:4751
 May 14 17:37:39 apparao-power-mac-g5 MyCocoaApp[123]:
 -[NSNextStepFrame(0x143610) lockFocus] failed with window=0x142e60,
 windowNumber=62, [self isHiddenOrHasHiddenAncestor]

 What's the backtrace?
 Set a breakpoint at objc_exception_throw to find out.

 —Jens

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

Re: Assertion failure in -[NSNextStepFrame lockFocus]

[Jens Alfke]

On 15 May '08, at 2:24 AM, Apparao Mulpuri wrote:


Here is the Stacktrace:


The binary backtrace is hard to decipher (and it has to be deciphered  
on the same computer, or at least one with the exact same system  
version and frameworks.) Instead follow my directions about setting a  
breakpoint.


—Jens

smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Assertion failure in -[NSNextStepFrame lockFocus]

[Jens Alfke]

On 15 May '08, at 3:41 AM, Apparao Mulpuri wrote:


Here is the complete stacktrace:


Thanks. This looks like a pretty normal backtrace (up until the  
exception), with only minimal involvement of your code, so it does  
seem like an AppKit bug. You should file a bug report, definitely  
including the backtrace, ideally including your program.


—Jens

smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Assertion failure in -[NSNextStepFrame lockFocus]

[Kyle Sluder]

On Thu, May 15, 2008 at 11:10 AM, Jens Alfke [EMAIL PROTECTED] wrote:
 Thanks. This looks like a pretty normal backtrace (up until the exception),
 with only minimal involvement of your code, so it does seem like an AppKit
 bug. You should file a bug report, definitely including the backtrace,
 ideally including your program.

And do this regardless of whether or not you think anyone else has
done so already.  If your bug gets marked as a dup, so be it; it lets
the engineers know that this issue is affecting multiple users.

--Kyle Sluder
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Assertion failure in -[NSNextStepFrame lockFocus]

[Apparao Mulpuri]

Thanks Jens and Kyle Sluder.

Actually my application is primarily targeted for Leopard OS, which is
not working due to this Exception. I am creating a new window and
setting window frame, where exception occurs.

Is there any other way for setting the Window frame?

- Apparao.

On 5/15/08, Kyle Sluder [EMAIL PROTECTED] wrote:
 On Thu, May 15, 2008 at 11:10 AM, Jens Alfke [EMAIL PROTECTED] wrote:
  Thanks. This looks like a pretty normal backtrace (up until the exception),
  with only minimal involvement of your code, so it does seem like an AppKit
  bug. You should file a bug report, definitely including the backtrace,
  ideally including your program.

 And do this regardless of whether or not you think anyone else has
 done so already.  If your bug gets marked as a dup, so be it; it lets
 the engineers know that this issue is affecting multiple users.

 --Kyle Sluder

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Assertion failure in -[NSNextStepFrame lockFocus]

[Kyle Sluder]

On Fri, May 16, 2008 at 1:26 AM, Apparao Mulpuri
[EMAIL PROTECTED] wrote:
 Actually my application is primarily targeted for Leopard OS, which is
 not working due to this Exception. I am creating a new window and
 setting window frame, where exception occurs.

What bothers me is that it looks like you're doing this in response to
a menu item being selected, which means this will be happening in the
run loop's event-tracking mode.  Perhaps you should defer this to the
next standard run of the run loop?

--Kyle Sluder
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Assertion failure in -[NSNextStepFrame lockFocus]

[Apparao Mulpuri]

HI,

   I have a Cocoa based multi monitor application,which will run on
Mac OS X 10.3.9 onwards.

   It is working as expected in 10.3.9  and Tiger os versions. But, in
Leopard 10.5.2, its giving following exception:

** Assertion failure in -[NSNextStepFrame lockFocus],
/SourceCache/AppKit/AppKit-949.27/AppKit.subproj/NSView.m:4751
May 14 17:37:39 apparao-power-mac-g5 MyCocoaApp[123]:
-[NSNextStepFrame(0x143610) lockFocus] failed with window=0x142e60,
windowNumber=62, [self isHiddenOrHasHiddenAncestor]

  For single monitor with Leopard its working fine. With secondary
monitor, its throwing above exception. In Secondary monitor case, i am
doing window(which is custom class of NSWindow and created in IB) copy
operation(using achieving and unarchieving) and displaying it on
secondary monitor.

  I am not getting any idea from the above exception. By google, i
found that, some one is experienced the same exception with custom
window creation on Leopard.

  Any pointers on this is really appreciated.

Thanks,
- Apparao.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Assertion failure in -[NSNextStepFrame lockFocus]

[Apparao Mulpuri]

Is it a known issue on Leopard. Is there any fix?

I am planning to file a bug in apple bugreporter. Is any one filed it already?.

- Apparao.

On Wed, May 14, 2008 at 7:00 PM, Apparao Mulpuri
[EMAIL PROTECTED] wrote:
 HI,

   I have a Cocoa based multi monitor application,which will run on
 Mac OS X 10.3.9 onwards.

   It is working as expected in 10.3.9  and Tiger os versions. But, in
 Leopard 10.5.2, its giving following exception:

 ** Assertion failure in -[NSNextStepFrame lockFocus],
 /SourceCache/AppKit/AppKit-949.27/AppKit.subproj/NSView.m:4751
 May 14 17:37:39 apparao-power-mac-g5 MyCocoaApp[123]:
 -[NSNextStepFrame(0x143610) lockFocus] failed with window=0x142e60,
 windowNumber=62, [self isHiddenOrHasHiddenAncestor]

  For single monitor with Leopard its working fine. With secondary
 monitor, its throwing above exception. In Secondary monitor case, i am
 doing window(which is custom class of NSWindow and created in IB) copy
 operation(using achieving and unarchieving) and displaying it on
 secondary monitor.

  I am not getting any idea from the above exception. By google, i
 found that, some one is experienced the same exception with custom
 window creation on Leopard.

  Any pointers on this is really appreciated.

 Thanks,
 - Apparao.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Assertion failure in -[NSNextStepFrame lockFocus]

[Jens Alfke]

On 14 May '08, at 9:17 PM, Apparao Mulpuri wrote:


** Assertion failure in -[NSNextStepFrame lockFocus],
/SourceCache/AppKit/AppKit-949.27/AppKit.subproj/NSView.m:4751
May 14 17:37:39 apparao-power-mac-g5 MyCocoaApp[123]:
-[NSNextStepFrame(0x143610) lockFocus] failed with window=0x142e60,
windowNumber=62, [self isHiddenOrHasHiddenAncestor]


What's the backtrace?
Set a breakpoint at objc_exception_throw to find out.

—Jens

smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]