I found that I can send a custom notification from the function that receives the menu item action to my ContentView, and that works, getting around the whole "this is not the view that you're searching for" junk. Pretty sure this will be the last SwiftUI app I'll ever write. I tried one before that should've been simple, but again I hit a wall of complexity and things that just aren't possible and went back to the glory that is Cocoa for that. At least things show up in the debugger there.

Well, I need more than a refresher course, since I've just been trying to understand how each piece of SwiftUI works when I come to it. I never been so stymied and angry at a language in all my 48 years of programming. Here's the relevant code. Comments say what works and what doesn't: @main struct SpeakotronikApp: App { @State public var contentView = ContentView(); @State var showFileImporter:Bool = false; var body:some Scene { WindowGroup { self.contentView .environment(langModel) } .commands { CommandGroup(after:.newItem) { Button("Import…") { self.showFileImporter = true; } .fileImporter(isPresented:$showFileImporter, allowedContentTypes:[.text], allowsMultipleSelection:false) { result in switch result { case .success(let urls): for url in urls { // Tell the content view to read the file and add new terms that will be translated: self.contentView.importTerms(url:url); } case .failure(let error): print("Error selecting file: \(error.localizedDescription)"); } } } } } } struct ContentView: View { @Environment(LangViewModel.self) private var langModel; @State private var selectedLang:Locale.Language = ...a language...; // This variable causes .translationTask to run when called from code contained in ContentView (.onChange), which works: @State var sequenceTranslationConfig:TranslationSession.Configuration?; var body: some View { VStack { ...buttons and stuff... } .onChange(of:selectedLang) { // Trigger the sequence translations to run: sequenceTranslationConfig = .init(source:Locale.current.language, target:selectedLang, preferredStrategy:.highFidelity); } .translationTask(sequenceTranslationConfig) { session in await langModel.translateSequence(using:session, terms:self.terms); } } public func importTerms(url:URL) { // Gain temporary permission to read security-scoped sandbox files guard url.startAccessingSecurityScopedResource() else { return } // Defer release of the system permission defer { url.stopAccessingSecurityScopedResource() } do { ...read file and do stuff with it... // Trigger my sequence translations to happen, which does NOT work: sequenceTranslationConfig = .init(source:Locale.current.language, target:selectedLang, preferredStrategy:.highFidelity); } catch { print("Error reading file: \(error.localizedDescription)") } } }

OK, so now the fileImporter is being run from the command in the app. It calls a function on the ContentView to import files. That function needs to do some other things to itself, so it sets the value of a @State TranslationSession.Configuration in the ContentView to a new instance, which is supposed to kick off a translationTask. Nothing happens, I assume because it's not being called from within a View hierarchy, but from the app. Why is it so difficult to make things work in SwiftUI?

That crossed my mind as well, but again, it feels icky to put the code in the app when only the ContentView should be muddied up with it. I'll do that and move on. It's too bad this SwiftUI stuff isn't friendlier. Thanks.

I tried moving showFileImporter to the app and sharing it in the environment, but Swift hates that. struct SpeakotronikApp: App { @State var showFileImporter:Bool = false; var body:some Scene { WindowGroup { ContentView() .environment(showFileImporter) } } Instance method 'environment' requires that 'Bool' be a class type Instance method 'environment' requires that 'Bool' conform to 'Observable'

You could use environment variables for showFileImporter and remove the contentView state var to solve the issue. I'd thought about that, but it seems like bad practice to keep a variable in the app when only the ContentView actually uses it. But then there are many things about Swift that are illogical. Note: in Swift, you don't need to end statements with semicolon. I know, yet I do, because I always have in all other languages I've ever used, and always will. They add important visual endings to each line of code. I missed one in my editing of the example in my original post.

Yeah, it's very, very too bad so many questions go unanswered around here. I'd have to search my project folder for that to even remember which app this was for. But that's an interesting workaround. I'll have to try it, if my problem is even still valid after all this time.

Today I noticed that when SB fails, the SBApplication object says isRunning is NO, but the InDesign application it's pointing to is still very much alive and running. If I create a new SBApplication when this happens and run the same script that just failed, it works fine. Something is screwing up the SBApplication in some way. I'll add this to the bug.

What's the "architecture" of that helper app? Is it a true "app" (meaning, in an app bundle, running an NSApplication loop, and simply marked "faceless")? Or is it something like an XPCService or a command-line tool? Also, how was it launched? The applescriptrunner helper app is just a command line app launched with NSTask, using a NSXPCConnection, et al. That app's main() creates an NSOperation subclass that handles all of the XPC communication and running of scripts (formerly via NSAppleScript, but now via ScriptingBridge). I assume this is communicating with the "server app", so there isn't a user-visible app either? If so, then my best guess would be that we're suspending the app or otherwise stopping/pausing its normal execution. It happens with both InDesign Desktop (UI) and InDesignServer (no UI). How long does it stay stuck like this? It doesn't actually "stick", it just returns nothing from InDesign when the script should return a result or throws an error. From the reply I got in my ticket for that situation (FB22065804), it's InDesign's bug that's causing this.

I've made a change to our app. We have a faceless helper app that we used to use for running all our scripts. It uses XPC for communication between it and the main app. It was developed many years ago when we needed to stop blocking the main thread when multiple jobs were running scripts. I updated it a few days ago to use ScriptingBridge (like we'd previously done to the main app). This has been used in production now for a couple days. We no longer experience crashes caused by the low level AE system (AECreateEmptyEvent, etc). That's the good news—the AE errors for one job no longer take out the app and any other jobs. I do still get problems that appear to be empty replies from telling the InDesignApplication (an SBApplication subclass) to doScript:ourScript. This mostly happens when running multiple jobs at once and when I switch our main app in and out of the foreground. I assume doing that jiggles a lot of Jell-o. I don't know what would cause that; the AE system, SB, or InDesign.

Hooboy, knowing if we've seen it on Intel machines will take some digging. The M1 Studios we have are 2022. Our ScriptingBridge code was added in June 2023. The first internal mention of errOSAInternalTableOverflow is December 2023. The M1 Studios weren't put into production until March 2024 (that's how slow our IT department moves). By this timeline, it appears we were seeing errOSAInternalTableOverflow on Intel. As for the actual crash described in this thread and bug, that I'm not sure about. I'm assuming that getting errOSAInternalTableOverflow and this crash are caused by the same underlying bug. No PowerPC Macs have been in use during my tenure at this job. Naturally, I figured it would be a very long time until a possible Apple fix would reach our production machines. Time to diagnose + time to fix & test + time to release + time for our IT department to OK the user of that version of macOS. I just might be retired by then. Moving the bulk of the "job" code to a separate helper app will be fairly substantial for our small team. I might've mentioned that during my stress testing to duplicate the problem, I tried using a class-level lock around the call into ScriptingBridge. That appeared to help, but made the app essentially single threaded, and that's not an option. I'll mess with adding a small delay, although that will be quite ugly in the dozen or so methods that we've rewritten to be full ScriptingBridge calls (multiple lines accessing objects and calling SB methods on the target app, rather than just telling the SB app to run an AppleScript). I'll also mention that today I tried having 2 jobs running, each hammering a different target SB app. At times one of the operation would freeze inside the AESendMessage: #0 0x0000000188941c34 in mach_msg2_trap () #1 0x0000000188954338 in mach_msg2_internal () #2 0x000000018894a764 in mach_msg_overwrite () #3 0x0000000188941fa8 in mach_msg () #4 0x0000000188a6ec0c in __CFRunLoopServiceMachPort () #5 0x0000000188a6d528 in __CFRunLoopRun () #6 0x0000000188a6c9e8 in CFRunLoopRunSpecific () #7 0x0000000190494198 in ___lldb_unnamed_symbol1373 () #8 0x000000019047098c in AESendMessage () #9 0x00000001d52402ac in -[SBAppContext sendEvent:error:] () #10 0x00000001d523988c in -[SBObject sendEvent:id:parameters:] () The other operation carried on running. Sometimes I could make it unfreeze by stopping in the debugger to see what it was doing, then continue. Then the other operation might freeze later. Etc. And sometimes, if I just let it sit long enough, the frozen operation would continue on its own, although I don't know if that ever happened while both operations were present and running.

Good idea. I often have most of that stuff turned on, but haven't lately. I ran with ASan on all this morning (running 2 jobs that constantly hammer InDesign Desktop with scripts) and only managed to get 2 occurrences of errOSAInternalTableOverflow, but no crashes or hangs.

Lucky me - it crashed today! Crash log and sysdiagnose uploaded to bug report FB21953216.

I've submitted bug FB22065804 and attached files created shortly after the error concerned. Oh, I'll add the time the error occurred to the bug. I forgot about that.

The test using a fake job did not cause a crash, only a hang of the "ProofProcessor - FAKE1" NSOperation. I'll grab a sysdiagnose the next time this happens, which could be tomorrow. There's currently one user's job that is repeatedly causing an exception to be thrown while sending AppleEvents via ScriptingBridge. It's probably related, but is not causing the same "2 jobs sending AEs and causing the crash" situation.