I wrote an AppleScript that takes a bunch of scanned jpegs with systematically named filenames and transfers information from the filename into the date and time fields. That all works fine, but I've got many more scans to do and I'd like to augment the script to include a progress meter because it takes a long time to run on e.g. 1000 photos. I've found basic progress meter examples online that involves commands like: set progress total steps to theImageCount set progress completed steps to 0 set progress description to "Processing Images..." set progress additional description to "Preparing to process." and they run OK in a separate dummy test case, however I'm getting syntax errors for such commands in my renaming script because (I think) they're inside a tell application "Photos" wrapper and it looks like Photos doesn't like those commands. A progress meter (in any AppleScript) should be a straightforward thing i.e. I can clearly define a total number of steps and I can clearly define the step number I'm currently on. I just want to display something like: I'd even be OK with just implementing something like: display dialog "blah blah" but that needs to be manually dismissed with each iteration of the loop, so that's no good. I also tried: display notification "blah blah" but that yields hundreds of notification boxes at the top right of my screen, so that's also impractical. I was even thinking maybe I could call some generic system progress meter with all the right variables via a "do shell script" command (although I have no idea how to do that). Something surely must be possible, but I just can't figure it out :-(. Could some kind soul please help me out. Thanks.

I need my application to copy some files, but using Finder. Now, I know all different methods and options to programmatically copy files using various APIs, but that's not the point here. I specifically need to use Finder for the purpose, so please, let's avoid eventual suggestions mentioning other ways to copy files. My first thought was to use the most simple approach, execute an AppleScript script using NSUserAppleScriptTask, but that turned out not to be ideal. It works fine, unless there already are files with same names at the copying destination. In such case, either the script execution ends with an error, reporting already existing files at the destination, or the existing files can be simply overridden by adding with overwrite option to duplicate command in the script. What I need is behaviour just like when Finder is used from the UI (drag'n'drop, copy/paste…); if there are existing files with same names at the destination, Finder should offer a "resolution panel", asking the user to "stop", "replace", "don't replace", "keep both" or "merge" (the latter in case of conflicting folders). So, I came to suspect that I could achieve such bahaviour by using Apple Events directly and passing kAEAlwaysInteract | kAECanSwitchLayer options to AESendMessage(). However, I can't figure out how to construct appropriate NSAppleEventDescriptor (nor old-style Carbon AppleEvent) objects and instruct Finder to copy files. This is where I came so far, providing srcFiles are source files (to be copied) URLs and dstFolder destination folder (to be copied into) URL: NSRunningApplication *finder = [[NSRunningApplication runningApplicationsWithBundleIdentifier:@"com.apple.finder"] firstObject]; if (!finder) { NSLog(@"Finder is not running."); return; } NSAppleEventDescriptor *finderDescriptor = [NSAppleEventDescriptor descriptorWithBundleIdentifier:[finder bundleIdentifier]]; NSAppleEventDescriptor *dstDescriptor = [NSAppleEventDescriptor descriptorWithString:[dstFolder path]]; NSAppleEventDescriptor *srcDescriptor = [NSAppleEventDescriptor listDescriptor]; for (NSURL *url in srcFiles) { NSAppleEventDescriptor *fileDescriptor = [NSAppleEventDescriptor descriptorWithString:[url path]]; [srcDescriptor insertDescriptor:fileDescriptor atIndex:([srcDescriptor numberOfItems] + 1)]; } NSAppleEventDescriptor *event = [NSAppleEventDescriptor appleEventWithEventClass:kAECoreSuite eventID:kAEClone targetDescriptor:finderDescriptor returnID:kAutoGenerateReturnID transactionID:kAnyTransactionID]; [event setParamDescriptor:srcDescriptor forKeyword:keyDirectObject]; [event setParamDescriptor:dstDescriptor forKeyword:keyAETarget]; NSError *error; NSAppleEventDescriptor *result = [event sendEventWithOptions:(NSAppleEventSendAlwaysInteract | NSAppleEventSendCanSwitchLayer) timeout:10.0 error:&error]; The code above executes without any error. The final result descriptor is a NULL descriptor ([NSAppleEventDescriptor nullDescriptor]) and there's no error returned (by reference). However, nothing happens, Finder remains silent and the application doesn't make macOS/TCC prompt for a permission to "automate Finder". I wonder if the approach above is correct and if I use correct parameters as arguments for all calling method/messages. I'm specially interested if passing keyAETarget is the right value in [event setParamDescriptor:dstDescriptor forKeyword:keyAETarget], since that one looks most suspicious to me. I'd really appreciate if anyone can help me with this. I'd also like to point out that I tried the same approach outlined above with old-style Carbon AppleEvent API, using AECreateDesc(), AECreateAppleEvent(), AEPutParamDesc() and AESendMessage()… All API calls succeeded, returning noErr, but again, nothing happened, Finder remained silent and no macOS/TCC prompt for a permission to "automate Finder". Any help is highly appreciated, thanks! -- Dragan

On iOS 18, I'm trying to index documents in Spotlight using the new combination of AppIntents+IndexedEntity. However, I don't seem to be able to index the textContent of the document. Only the displayName seems to be indexed. As recommended, I start with the defaultAttributeSet: /// I call this function to index in Spotlight static func indexInSpotlight(document: Document) async { do { if let entity = document.toEntity { try await CSSearchableIndex.default().indexAppEntities([entity]) } } catch { DLog("Spotlight: could not index document: \(document.name ?? "")") } } /// This is the corresponding IndexedEntity with the attributeSet @available(iOS 18, *) extension DocumentEntity { var attributeSet: CSSearchableItemAttributeSet { let attributeSet = defaultAttributeSet attributeSet.title = title attributeSet.displayName = title attributeSet.textContent = docContent attributeSet.thumbnailData = thumbnailData attributeSet.kind = "document" attributeSet.creator = Constants.APP_NAME return attributeSet } } How can I have more that the displayName to be indexed? Thanks :-)

AppleScript for the Music app no longer supports the current track event. Before macOS Tahoe, running the following script in Script Editor would return the current track information: tell application "Music" return name of current track end tell However, when I run this script on a device with macOS 26 Tahoe, I receive this error: "Result: error "Music got an error: Can’t get name of current track." number -1728 from name of current track” I've tested this extensively, and here are my findings: Going to the “songs” tab and playing something from there makes everything work. Playing any song directly will make it work with current track UNLESS this song is NOT in your Music library (either added through Apple Music or uploaded). If you play a song not in your library, current track is not updated even if you clicked on it specifically. Playing an album (in your library obviously) makes all the tracks within it appear in current track until autoplay takes over. Any autoplayed track won’t appear in current track even if in your library (unless: see the last bulletpoint) Music played through the “songs” tab all appear in current track even if autoplay kicks in. I assume this is because this tab is an iTunes legacy (visually and under the hood) and doesn’t use the modern autoplay. This tab also won’t play non-library songs unlike the “albums” tab which seems to use the correct autoplay and suffers the same symptoms as the “recently added”, “home”, “radio”, etc… tabs. Is this a bug, or has Apple simply deprecated this functionality?

Hello. How to write this command correctly on a Macbook, in the script editor, so that I can click the "Run script" button and the script will give the result: if there is no folder, then report that there is no folder, if there is a folder, then report that the folder exists. do shell script "test -d 'Users/user/Desktop/New folder'" Now, if the folder exists, an empty string ("") is returned, if the folder does not exist, the script editor reports that an error has occurred. In general, my task is to write a script that checks the existence of a folder.

Description The Shortcut Automation Trigger Transaction frequently times out, ultimately causing the shortcut automation to fail. Please see the attached trace for details. Additionally, the Trigger is activated even when the Transaction is declined. Details In the trace I see the error: [WFWalletTransactionProvider observeForUpdatesWithInitialTransactionIfNeeded:transactionIdentifier:completion:]_block_invoke Hit timeout waiting for transaction with identifier: <private>, finishing. Open bug report: FB14035016

Not quite but maybe sorta related to the errOSAInternalTableOverflow problem I asked about in a different thread, this one deals with crashes our app gets (and much more frequently lately after recent OS updates (15.7.3) are OK'd by our IT department). Our app can run multiple jobs concurrently, each in their own NSOperation. Each op creates its own SBApplication instance that controls unique instances of InDesignServer. What I'm seeing recently is lots of crashes happening while multiple ops are calling into ScriptingBridge. Shown at the bottom is one of the stack crawls from one of the threads. I've trimmed all but the last of our code. Other threads have a similar stack crawl. In searching for answers, Google's AI overview mentions "If you must use multiple threads, ensure that each thread creates its own SBApplication instance…" Which is what we do. No thread can reach another thread's SBApplication instance. Is that statement a lie? Do I need to lock around every ScriptingBridge call (which is going to severely slow things down)? 0 AE 0x1a7dba8d4 0x1a7d80000 + 239828 1 AE 0x1a7d826d8 AEProcessMessage + 3496 2 AE 0x1a7d8f210 0x1a7d80000 + 61968 3 AE 0x1a7d91978 0x1a7d80000 + 72056 4 AE 0x1a7d91764 0x1a7d80000 + 71524 5 CoreFoundation 0x1a0396a64 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28 6 CoreFoundation 0x1a03969f8 __CFRunLoopDoSource0 + 172 7 CoreFoundation 0x1a0396764 __CFRunLoopDoSources0 + 232 8 CoreFoundation 0x1a03953b8 __CFRunLoopRun + 840 9 CoreFoundation 0x1a03949e8 CFRunLoopRunSpecific + 572 10 AE 0x1a7dbc108 0x1a7d80000 + 246024 11 AE 0x1a7d988fc AESendMessage + 4724 12 ScriptingBridge 0x1ecb652ac -[SBAppContext sendEvent:error:] + 80 13 ScriptingBridge 0x1ecb5eb4c -[SBObject sendEvent:id:keys:values:count:] + 216 14 ScriptingBridge 0x1ecb6890c -[SBCommandThunk invoke:] + 376 15 CoreFoundation 0x1a037594c ___forwarding___ + 956 16 CoreFoundation 0x1a03754d0 _CF_forwarding_prep_0 + 96 17 RRD 0x1027fca18 -[AppleScriptHelper runAppleScript:withSubstitutionValues:usingSBApp:] + 1036