Why isn't entry box open when gettext is invoked?

Panorama X
21

I just installed this routine in my calendar database when I saw GetText wasn’t opening ready to edit. It makes entering info for the text displays look much more professional than before. I did customize the parameter “theText” to show the existing value as the default. If it is blank, if you hit the enter button or ok button, your prior data is erased. This way, it reverts to what was there before…

Thanks to Gary and the others who contributed and elucidated the various aspects of getting it to work.

22

This is a bug that Apple introduced a while ago, I think macOS 10.13. It worked in earlier versions of macOS.

With help from an Apple engineer a workaround has been found for this, the fix will be included in Panorama X 10.2.

23

I also have found this “gettext” problem so irritating that I don’t use “gettext” in my procedures. Instead, I use:

supergettext (yourfieldname),{title="(yourfieldname)" height=100 width=150 font=Monaco style=bold size=18 titleheight=5 buttons=“OK;CANCEL”}
if info(“DialogTrigger”) = “CANCEL”
STOP
endif
This gives me an open entry box. Pressing ENTER once will not close the box, allowing you to add to, or correct the entry. Pressing ENTER again closes the box and makes the change to the field.

24

@admin, Apparently this is a problem again in OS Tahoe 26.

gettext no longer automatically focuses the entry field when it opens.

Could you please confirm?

25

Apple broke this years ago. According to my notes, an Apple engineer helped me to code a workaround hack at the labs at WWDC 2019. So six years ago. It sounds like Apple has now made a change that breaks this hack, which isn’t too surprising, as the hack technique is a bit fragile. Unfortunately I don’t have any Apple engineers on speed dial, so it may take quite a while to resolve this. If I recall correctly, the first time Apple broke this it took over a year to get the solution (i.e. until I found the right engineer at an in person WWDC Lab session). I’m not saying it will take another year, but I also don’t want to set any expectations for an easy fix.

26

This might be a shot in the dark, but I found this information that could help addressing the issue with gettext no longer focusing the entry field in Tahoe OS:

Tahoe changed some NSAlert / dialog internals (layout and responder behavior), which can affect which control becomes first responder.
Developers have long had to explicitly set the initial first responder for an alert’s text field (for example via alert.window.initialFirstResponder = textField) rather than assuming the system will focus it.

Only for Jim to confirm if this is useful.

27

I found this information

Where did you find it? Did you mean to include a link? Is there more to it than this pull quote? With just what you posted here, this is not useful, it feels like there is a lot more missing information.

I did a google search on the exact text you posted, and came up with nothing, though of course Gemini generated some slop. Which is making me wonder - is this from ChatGPT or some other LLM? If so, then I think it is a dead end.

28

Hi Jim, Great guess!, I used chatGPT to describe the symptom associated to Tahoe OS. This time I requested the data source, which is pointing to the Apple Developer Documentation, so no specific page. This is what it came out with, hopefully it’s useful data:

Apple AppKit documentation on NSAlert (primary reference)

Website: Apple Developer Documentation
Key class: NSAlert (with accessory views)

This is the most important reference. GetText is almost certainly implemented using:

  • NSAlert
  • an accessory view containing an NSTextField
  • default buttons (OK, Cancel)

Apple explicitly states that:

  • Alerts decide their own default key view
  • The system may focus a button (often Cancel) unless the app explicitly assigns first responder

On newer macOS releases (including Tahoe), Apple has tightened and changed this behavior.

How to Fix:

  • Explicitly call makeFirstResponder: on the text field
  • Do it after the alert is presented, not before

This is not optional anymore.

29

I requested the data source, which is pointing to the Apple Developer Documentation

I call BS on the data source (on the LLM, not you).

Here’s Apple’s official documentation covering NSAlert. There is absolutely nothing on this page mentioning makeFirstResponder. Note that I never found this in any documentation, instead I was assisted at a WWDC Lab in 2019 by an Apple engineer (thank you Troy!).

This page does link to more extensive documentation about dialogs and special panels.

Note the copyright page on this more detailed documentation - 2009. That’s 17 years ago - before the first line of code in Panorama X was written!

On the other hand, the advice to call makeFirstResponder: is correct. Here’s the code in Panorama that does this.

image
image1056×656 68 KB

I’m kind of curious where ChatGPT got this information, since it didn’t get it from official Apple documentation. Just now I found ONE reference to this on the web, on a Stack Overflow post from 2019, a few months after my WWDC lab. However, I don’t think this is where this came from, because this post uses Swift, not Objective-C, and it says that makeFirstResponder doesn’t work!

So I have no idea where ChatGPT got this answer. Maybe from scanning a private code repo? (If it was a public repo, I think it should have shown up in Google.) In any case, this is an answer I already got from an Apple engineer, and also an answer that is around a decade old (the problem had already been occurring for at least a couple of years in 2019). Definitely not a Tahoe specific answer.

Some people are apparently having good results using LLMs for JavaScript and Python, where there is a huge corpus of public material that can be used for training. In my opinion, trying to use an LLM for Objective-C and/or AppKit is not going to get productive results. Basically, I think it is a waste of time. There’s unlikely to be more training material becoming available on these topics, so I don’t see this changing ever unless somehow these LLMs get access to private source code repos.

By the way, I’m told that even for Swift and SwiftUI LLMs often are very problematic, possibly because Swift and SwiftUI are changing so rapidly that the training material is badly out of date. So it’s very common for the LLM to spit out obsolete information - of course it presents this obsolete information in a cheerful and confident manner!! :100:

30

Thank you for taking the time to look into this, Jim. As I mentioned, it was a bit of a long shot to try to help without any insight into what’s under the hood of your code.