This sounded like an interesting puzzle so I did a bit of experimenting with the following code:-(void)doStuff { NSArray *theTabs = [myWindow tabbedWindows]; NSMutableArray *tabDocs = [[NSMutableArray alloc] init]; if([theTabs count] > 1) { for(NSInteger i = 0; i < [theTabs count]; i++) { [tabDocs addObject:[[NSDocumentController sharedDocumentController] documentForWindow:[theTabs objectAtIndex:i]]]; } } NSArray *theDocuments = [[NSDocumentController sharedDocumentController] documents]; NSLog(@"tabs %@ docs: %@",tabDocs, theDocuments); }I put this in the WindowController with its window named myWindow in an IBOutlet. I suspect a better place for this code would maybe be in the DocumentController.When I run this, if I have one window with multiple tabs, the array of documents in theDocuments matches the documents in tabDocs. If a tabbed window is dragged out then the arrays no longer match. Maybe this can give you a clue for how to solve your problem.

That answer is obvious--it leaks because it's a guy.

I don't know if what I am about to describe pertains to your situation but here is something I have found: When I am building an app, I often create groups to reduce the clutter and then as I build and expand the app, I drag certain headers and methods into newly created groups. This worked fine in the past but XCode 11 doesn't like this. I would get errors that header files could not be found yet the app would build and run properly. The solution, by trial and error, was to drag all of the headers and methods out of the groups, put them in the root folder of the app, and delete the now empty groups. Then, to create the groups I wanted, I selected certain headers and methods and created a group with selection. This solved all my wonky errors of not being able to find some headers.

I would be a bit concerned about having these lines of code inside the shouldBeginEditing method: [self setTableViewController:[[UITableViewController alloc] initWithStyle:UITableViewStylePlain]]; [self->_tableViewController.tableView setDelegate:self]; [self->_tableViewController.tableView setDataSource:self]; [self setNormalSearchPopOverController:[[UIPopoverController alloc] initWithContentViewController:self->_tableViewController]]; [self->_normalSearchPopOverController setDelegate:self];

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.

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.

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.

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.

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.

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.

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.

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

I am not detecting any memory issues.

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.