I just noticed that when closing a new document with edits in MacOS Sonoma that it skips the Save/Don't Save/Cancel panel and goes directly to default NSSavePanel with Delete/Cancel/Save buttons. The problem is that when I click "Delete" nothing happens. It should have simple solution, but I could not find anything. How does one respond to the "Delete" button? My undocumented (as far as I can tell) hack was to implement document:didSave:contextinfo selector for runModalSavePanelForSaveOperation. It appears that in this method for a new document: Delete button has didSave=YES (even though it did not save) and the document fileURL nil Cancel button has didSave=NO and document fileURL nil Save button has didSave=YES and document filieURL to saved file I can handle Delete button this way, but since it is not a documented method, it make me uncomfortable. For example what happens is user clicks "Save", but the save has an error? As an aside, since Apple is now working with ChatGPT, I thought it might provide some help. I asked it how I can respond to "Delete" button in MacOS Sonoma and it said to implement deleteDocument: in your NSDocument subclass. I pointed out to ChatGPT that deleteDocument: does not exist. It said "you are correct" and you should instead check the returned result from runModalSavePanelForSaveOperation and look for "stop" action. I pointed out to ChatGPT that runModalSavePanelForSaveOperation is void and does not return a result, it said again, "you are correct." It gave a third option which basically said to override runModalSavePanelForSaveOperation and build your own save panel from scratch. I didn't know if I should trust this answer. I reverted to my hack and wrote this post. Also ChatGPT never apologized for wasting my time with the wrong answers.

I have a app I have developed over last 17 years and I noticed an NSTextView field that I set up without word wrapping no longer scrolled in the horizontal direction. I turned off wrapping with a method from Apple documention (last updated 2019) with key code being [[theTextView enclosingScrollView] setHasHorizontalScroller:YES]; [theTextView setHorizontallyResizable:YES]; [theTextView setAutoresizingMask:(NSViewWidthSizable | NSViewHeightSizable)]; [[theTextView textContainer] setContainerSize:NSMakeSize(FLT_MAX, FLT_MAX)]; [[theTextView textContainer] setWidthTracksTextView:NO]; It adds horizontal scroll bars, makes text view resizable in horizontal direction, makes the text container very wide, and sets container to track text view width changes. But in MacOS 10.12 (or newer, I was using 10.13), the text view no longer resizes horizontally and one cannot scroll long lines in the horizontal direction. After 3-4 hours of trying various thinks, I found this tidbit in NSTextView documentsion In macOS 12 and later, if you explicitly call the layoutManager property on a text view or text container, the framework reverts to a compatibility mode that uses NSLayoutManager. I was then able to restore word wrapping with scrolling by adding the line NSLayoutManager *lm = [theTextView layoutManager] This call was enough; no need to use the layout manager. My code now works again. My problem is solved, but the solution raises the questions --- what is "incompatibility" mode if this line is not called? Do I have to find all my NSTextViews and insert this call otherwise things won't work in MacOS 10.12+? And finally, what are the benefits of using "incompatibility" mode, which seems to stop using NSLayoutManager, and how does one do layout in that mode? The brief developer documentation in XCode did not make that clear.

Because my MacOS app has a user-programmable interface, my coding creates lots of interface elements programmatically. Soon after an update to MacOS 14.3.1, I found some of these element (NSTextFields) did not draw correctly. I had not changed any code but the appearance changed for the worse (the text in the text field did not appear). I then noticed: The problem occurs when I compile in XCode 15.2 (15C500b) Version and run on computer with Sonoma 14.3.1 (23D60) If I instead compile in XCode Version 14.1 (14B47b) on Ventura 13.0.1 (22A400) and copy the app to my computer with Sonoma 14.3.1 (23D60)all works as expected. These results seem to imply XCode 15.2 does not compile correctly? Is this known issue or is there a fix?

I have been able to get rid of reported memory leaks in Instruments not by fixing a leak but by adding some lines (like releasing a previous nil object) that convinced Instruments it is not a leak. But I am stuck are some I cannot stop Instruments from reporting. It reports a leak in this code if(expr.length>0) { // add previous Atomic Atomic *atom = [[Atomic alloc] initWithString:[string substringWithRange:expr] isNumber:aNum]; [exprTokens addObject:atom]; [atom release]; } } and it underlines the substringWithRange method. I changed code to explicitly release atom and I assumed substringWithRange would return an autoreleased new string. I am aware Instruments tells you where the leaked object is created and not where it is leak, but only things created here are atom and a sub string and atom is released immediately. The initWithString method might do it, but I don't find anything there. Also, while running instruments, this code is 8542 times (I am pretty sure always in the same context) and Instruments says it only leaks 61 times. I don't now if there is misunderstanding are a code problem?

In genealogy software, I have an NSView that displays a family tree where each person is in a subview. Before Sequoia, the subviews would draw in the order I add them to the parent NSView. For some reason, Sequoia calls drawRect in reverse order. For example, a tree with cells for son, father, and mother used to be drawn in that order, but Sequoia draws them as mother, father, and son. For static cell placement it would not matter, but these trees dynamically adjust as users change data or expand and contract branches from the tree. Drawing them in the wrong order messes up all the logic and many trees are corrupted. Has the new drawing order been implemented for some reason and can it be changed? Is it documented?

My application can be controlled by scripts using AppleScript, python (through scripting bridge), or my own internal scripting language in a script thread. I just noticed that scripts that need to know the current front window have stopped working in Ventura. I find the front window as the first relevant window in [NSApp orderedWindows] (in Objective C). I found the problem with Ventura by adding some debugging output as follows: Run a script thread to control my application When a new window is needed, this thread uses performSelectorOnMainThread to create a window and waits for it to appear and to get added to the document. Before returning from main thread selector, the ordered windows are checked and they are correct (the new window is an AncestorController). DEBUG: check window order after creating an AncestorController DEBUG: frontGEDCOMController windows are: ...1 of 2 <NSWindow: 0x123691e20> <AncestorController: 0x600001fc50e0> ...2 of 2 <NSWindow: 0x123641ad0> <IndexController: 0x6000019c0c40> ...current front window is AncestorController Immediately on return to script thread, however, another performSelectorOnMainThread is called to check the order of the windows again and it has changed in an instant to the wrong order (wrong because the AncestorController is still in front). DEBUG: recheck window order after 0.000000 seconds DEBUG: frontGEDCOMController windows are: ...1 of 2 <NSWindow: 0x123641ad0> <IndexController: 0x6000019c0c40> ...2 of 2 <NSWindow: 0x123691e20> <AncestorController: 0x600001fc50e0> ...front window type is IndexController But, if I sleep the thread, the order changes back to correct order in <= 1/30 second DEBUG: recheck window order after 0.033333 seconds DEBUG: frontGEDCOMController windows are: ...1 of 2 <NSWindow: 0x123691e20> <AncestorController: 0x600001fc50e0> ...2 of 2 <NSWindow: 0x123641ad0> <IndexController: 0x6000019c0c40> ... front window type is AncestorController This issue is new to Ventura. For some reason Ventura adds a window to the list in the correct position. It then movies to the wrong possible for a short amount of time before then returning to the correct position. That did not happen in MacOS 12.x or earlier. Now maybe I can find all the places my scripts that need to pause for Ventura to get things right, but it would be better to know why it has happened and then know where I need to insert Ventura hacks? Or is there another way that can reliably get ordered windows in Ventura? Curiously this problem does not occur when scripting by AppleScript. Maybe that is just so slow that pauses happen all the time anyway. I did find an alternative method to get ordered windows introduced in 10.12: enumerateWindowsWithOptions:usingBlock: with option NSWindowListOrderedFrontToBack but it is identical to using orderedWindows (i.e., gets the order wrong for a while).

I have a window with a split view and I want top and bottom to scroll a subclass of NSTextView. I set them up identically and linked to a custom window controller class, but when the nib loads only one gets the custom class. The other one always gets plain NSTextView class. Even more curious, the one that does not get custom class is IBOutlet named "outputText" in my code. If I change the name to something else the nib loads nothing at all. If I change back to outputText, it gets NSTextView again. In fact, it is loaded as NSTextView and assigned to my IBOutlet even if I do not make that connection in the nib file. I tried clean and rebuild several times, but no help. I even looked in the raw nib XML and can see custom class is set, but it is not used. The connections in my window controller class are IBOutlet TextViewWithHelpMenu *commandText; IBOutlet TextViewWithHelpMenu *outputText; Attached are pictures of how these are connected the same way (but only one works):