It sounds like you aren't code signing your app or notorizing it.https://developer.apple.com/developer-id/

// This is in an NSDocument class //------------------------------------------------------------------------------------------------ -(IBAction)saveMyAttStringToPDF:(id)sender { // if you need to do some stuff, like put an attributed string in place, do it here. [super saveDocumentToPDF:sender]; // you could also connect your menuItem directly to the saveDocumentToPDF: action and eliminate this piece of code. } //------------------------------------------------------------------------------------------------ -(NSPrintInfo *)thePrintInfo { NSPrintInfo *printInfo = [NSPrintInfo sharedPrintInfo]; // get the shared [printInfo setHorizontalPagination:NSFitPagination]; [printInfo setVerticallyCentered:NO]; [printInfo setHorizontallyCentered:NO]; [printInfo setLeftMargin:72.0]; [printInfo setRightMargin:72.0]; [printInfo setTopMargin:72.0]; [printInfo setBottomMargin:72.0]; return printInfo; } //------------------------------------------------------------------------------------------------ -(NSPrintOperation *)printOperationWithSettings:(NSDictionary *)printSettings error:(NSError **)outError { NSAttributedString *attString = myAttributedString; NSPrintInfo *aPrintInfo = [self thePrintInfo]; // the rect doesn’t really matter—the textView is used to assemble the pieces NSRect theRect = NSMakeRect (0, 0, 468.0, 300.0); NSTextView *printTextView = [[NSTextView alloc] initWithFrame:theRect]; NSTextStorage *printStorage = [[NSTextStorage alloc] initWithAttributedString:attString]; [[printTextView layoutManager] replaceTextStorage:printStorage]; NSPrintOperation *op = [NSPrintOperation printOperationWithView:printTextView printInfo:aPrintInfo]; [op setShowsPrintPanel:NO]; [op setShowsProgressPanel:YES]; return op; }

I am wondering if line 18 should come before lines 13 and 14?Do you need to use quartz? If it was me, I would using printing and print it to a pdf. I can post code to do that if you want.I posted some code but it is being moderated (for three days now).

If this is a non-document based app, then I suspect you will have to implement the undo manager yourself. The undo manager comes for free with document based apps and mostly works out of the box. https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/UndoArchitecture/UndoArchitecture.html#//apple_ref/doc/uid/10000010-SW1

The crash is very infrequent--say maybe once or twice a month at most. The app is a text editor, NSDocument based. I am doing multiple pages similar to the page view mode in the TextEdit sample code--multiple textViews put in an NSView that is the overall "container" that holds all the textViews. That NSView is in a scrollview. This scrollView is created in interface builder and is there for the life of the app. Everything contained in the scrollView is created programmatically. The NSView that it is scrolling is created once and exists for the life of the app. The textViews get added or removed as needed.The only thing I am doing when it crashes is slowly scrolling a document up and down. For example, if I have a 20 page document and I go in it to edit, make changes, etc. So I open it and slowly scroll up and down to try to remember what I already did (memory isn't what it used to be). It is just a leisurely scrolling and all of a sudden, the app just crashes and disappears and I get the crash report. But as I said, it is very infrequent. I have thought about this and I can't point my finger at what could be causing it. During this event, my app isn't doing anything like adding or removing pages or stuff like that. It is just scrolling an existing NSView that contains what I said above. Thank you for your help.

I am not detecting any memory issues.

I don't have an answer for you but I do have a comment. I was getting a crash that, from my memory, looks very similar to your crash. The thing that stands out for me is the stepper cell. I eventually figured out a work-around that isn't elegant but stopped the crash.Edit to add this: I should clarify, it wasn't the stepper cell that was the culprit, that is what caught my eye in your post. I replaced the stepper cell with another method of changing the value and the crash still existed until I did my hack.Another edit 2/29/2020Did you ever find a solution? As I mentioned, I had a hack I used to get around the crash. It involved putting a small portion of code in a perform selector with delay. I didn't like that but it worked. I have since found a slightly better solution:dispatch_async (dispatch_get_main_queue(),^{ // do stuff });Some background on the code in question. A document based app with multiple pages of text. A dropdown sheet has a bunch of buttons to click for changing margins, etc. Every time a margin is changed, then the main document is updated. The crash always happened when it was updating the size of the textContainer. My original hack involved putting the container size update in the delay. I suppose this gave the app time to wander through the thread once before it updated the container. Anyway, putting the code to update the document and container in the code above seems to have solved my problem. While not a "bug fix," this might be something for you to explore.

Yes I can. I didn't want to post too much spam in the original thread.I changed the name to MyApp--seriously, this isn't the real name of the app!Process: MyApp [742]Path: /Applications/MyApp.app/Contents/MacOS/MyAppIdentifier: com.xxxxxxxx.xxxxxxxVersion: 3.7.5 (655)Code Type: X86-64 (Native)Parent Process: ??? [1]Responsible: MyApp [742]User ID: 501Date/Time: 2020-02-20 07:26:42.828 -0600OS Version: Mac OS X 10.14.6 (18G95)Report Version: 12Anonymous UUID: BEC7CDC5-D62B-AA47-E79D-00333BADAC10Sleep/Wake UUID: 3EAF2810-813F-417F-88AA-A2B2F9A6C887Time Awake Since Boot: 2100 secondsTime Since Wake: 650 secondsSystem Integrity Protection: enabledCrashed Thread: 0 Dispatch queue: com.apple.main-threadException Type: EXC_BAD_ACCESS (SIGSEGV)Exception Codes: KERN_INVALID_ADDRESS at 0x00004411b0845158Exception Note: EXC_CORPSE_NOTIFYTermination Signal: Segmentation fault: 11Termination Reason: Namespace SIGNAL, Code 0xbTerminating Process: exc handler [742]VM Regions Near 0x4411b0845158: MALLOC_LARGE_REUSABLE 00000001189db000-00000001199db000 [ 16.0M] rw-/rwx SM=PRV --> MALLOC_NANO 0000600000000000-0000600008000000 [128.0M] rw-/rwx SM=PRV Application Specific Information:objc_msgSend() selector name: scrollView:scrollWheelWithEvent:Thread 0 Crashed:: Dispatch queue: com.apple.main-thread0 libobjc.A.dylib 0x00007fff762bc69d objc_msgSend + 291 com.apple.AppKit 0x00007fff49366033 forwardMethod + 2112 com.apple.AppKit 0x00007fff49414bb2 -[NSView scrollWheel:] + 3413 com.apple.AppKit 0x00007fff49366033 forwardMethod + 2114 com.apple.AppKit 0x00007fff49414bb2 -[NSView scrollWheel:] + 3415 com.apple.AppKit 0x00007fff49366033 forwardMethod + 2116 com.apple.AppKit 0x00007fff49414bb2 -[NSView scrollWheel:] + 3417 com.apple.AppKit 0x00007fff49366033 forwardMethod + 2118 com.apple.AppKit 0x00007fff49414bb2 -[NSView scrollWheel:] + 3419 com.apple.AppKit 0x00007fff49366033 forwardMethod + 21110 com.apple.AppKit 0x00007fff49414bb2 -[NSView scrollWheel:] + 34111 com.apple.AppKit 0x00007fff492a2367 -[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] + 684012 com.apple.AppKit 0x00007fff492a0667 -[NSWindow(NSEventRouting) sendEvent:] + 47813 com.apple.AppKit 0x00007fff49140626 -[NSApplication(NSEvent) sendEvent:] + 231014 com.apple.AppKit 0x00007fff4912e5e0 -[NSApplication run] + 75515 com.apple.AppKit 0x00007fff4911dae8 NSApplicationMain + 77716 libdyld.dylib 0x00007fff77a983d5 start + 1

I don't override any of the scrolling functions nor do I subclass the scrollView. I have been using this code for about 5 years and haven't had this issue until the past few months. There really isn't any code to show that is relevant.

As I said, "Setting the alignment doesn't have any effect when drawing with the drawAtPoint--yes, your string is right aligned but it is a string of only the length needed for the text so it really doesn't do anything."Your code is drawing the text right where you would expect it to draw--at the X. If you have multiple lines, then either draw each line with the code I suggested or think about another approach--maybe putting the text into a textField or textView with the text right aligned and then placing the field/textView at the location you desire (set the background color of the field/textView to clearColor so it doesn't appear as a box on top of your image--only the text will show. I would go with the first approach and draw each line separately.

Try this:NSAttributedString *attString = ???? CGFloat stringWidth = [attString size].width; CGFloat stringY = borderSize.height - 48; CGFloat stringX = borderSize.width - [thePrintInfo rightMargin] - stringWidth; [attString drawAtPoint:NSMakePoint(stringX, stringY)];I use this in a print routine to draw a footer on the bottom right of the page. You could adapt it for your needs.Since I am calculating from the right side of the page, I get the right margin X value and then subtract the width of the string, stringwidth, to get the starting position of X to draw. In this case, borderSize.width is the overall width, then subtract the width of the margin and the width of the attString. Setting the alignment doesn't have any effect when drawing with the drawAtPoint--yes, your string is right aligned but it is a string of only the length needed for the text so it really doesn't do anything.

Because I have about 120 student papers to grade over the next few days, I have been thinking about your problem! For some strange reason, Objective C is a way for me to relax. Anyway, some thoughts:From the NSDocumentController documentation:https://developer.apple.com/documentation/appkit/nsdocumentcontroller?language=objc"In some situations, it is worthwhile to subclass NSDocumentController in non-NSDocument-based apps to get some of its features. For example, the NSDocumentController management of the Open Recent menu is useful in apps that don’t use subclasses of NSDocument."If I were designing a game, which I have very little experience doing so, I would probably imagine the game "engine" portion distinctly separate from the data in the games that are played. Meaning this--each game would generate data associated with it (player locations, nerf balls dropped, goals achieved, parts of map explored, etc.). This data would be stored in a separate file and is loaded by the app to either start a new game (default set of data) or resume a game. This is not much different than a text editing app in concept--it's just the data that is different and the way it is displayed is different. So, I would look at saving games and using the Open Recents feature that is already available when using NSDocumentController. Using this approach would allow you to have many previous games or prior levels achieved in a game saved and available for immediate launch from the dock icon. NSDocumentController gives you control over what, how many, etc. is in the open recents menu. Just a thought.

Have you seen this?https://developer.apple.com/library/archive/samplecode/DockBrowser/Introduction/Intro.html#//apple_ref/doc/uid/DTS10000695While its main focus is using bonjour and net, the customization of the dock tile is also a part of it.

Hence my suggestion to use NSLog/print statements to verify and to also explore the possibility of using windowDidBecomeKey if it is relevant to this code.

I would put some NSLog statements (print if using swift?) in the viewDidAppear and viewDidLayout so you can verify which one is being called last. That might help you determine where to put the makeFirstResponder. I have found that sometimes it is necessary to put a short delay before calling some things on setup to give everything time to settle in. You might also try-(void)performSelectorOnMainThread:(SEL)aSelector withObject:(id)arg waitUntilDone:(BOOL)wait;You might also experiment with putting the makeFirstResponder in the windowDidBecomeKey notification if this part of your code responds to that notification. The windowDidBecomeKey is usually one of the last things to fire when an app and its window is coming up. Keep in mind that this notification will fire each time the window becomes key. The windowDidLoad might be another place to explore if it is relevant to this part of your code.