Post not yet marked as solved
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?
Post not yet marked as solved
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.
Post not yet marked as solved
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):
Post not yet marked as solved
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).
Post not yet marked as solved
I found a bug in XCode 11.6 and/or Catalina 10.15.6. I have a work around listed below, but wondered if this a general problem that should cause concern?
In brief, I extended NSString class in Objective C with some personal convenience methods. Here is simplified header for "MyStringAdditiotions" showing just one convenience method:
@interface NSString (MyStringAdditions) (NSString *)unquote;
@end
The one method is code I wrote a long time ago to remove white space and then if needed remove quotes on a string using such code as
NSString *myString = "	\"quoted text\"";
NSString *uqString = [myString unquote];
to return just uqString = quoted text.
The code itself is irrelevant and I am sure it is correct, but I got reports from users that it stopped working in Catalina. I was unable to reproduce their problems until I noticed that when I compile and run my app in XCode it works fine, but if I quit XCode and launch the app just compiled in XCode directly in Catalina, in runs differently and quotes and not removed. I tried NSLog() message in my unquote method. Those messages appear when running in XCode, but not when running in Catalina.
In summary, Catalina is not calling my convenience method. It is not, however, universal. I have lots of other methods in "MyStringAdditions" that are called correctly in Catalina. So far it appears only to be "unquote", but I cannot be sure and I don't know why the problem (hence the concern).
Two ways to fix it are to rename the method (e.g., to myUnquote) or to avoid using Objective C methods to extend a class (i.e., move the code to some other class). I thought maybe it was a naming conflict, but a search of developer documentation does not return any results for "unquote" in Objective C for NSString. Furthermore, if there was a conflict, it should affect running in XCode the same as running in Catalina (or at least give a warning of a conflict).
OSParticulas.