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  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  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  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  
 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  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  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  
>>> 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  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  
>> 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  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 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

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

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

This 

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]

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]