Applescript Error -10810 - macos

I have an Applescript that runs fine on my Macbook Retina but fails on a Mac Mini.
Both are running MacOS 10.9.2.
After peeling the onion a bit I'm able to reproduce the problem with a one-line Applescript:
tell application "MidiPipe" to activate
On the Mini that throws the error:
An error of type -10810 has occurred.
On the Macbook the MidiPipe application opens.
MidiPipe works normally on the Mini when started from the Finder or from Launchpad.
Google provides no insight into this error.

Well, I found this: http://www.thexlab.com/faqs/error-10810.html and this: http://osxdaily.com/2010/02/09/mac-error-10810/ and this: http://forums.adobe.com/thread/1389805 . At least one of these suggests a RAM problem.
But just to make sure you've tried every weird variation, have you tried the following:
1) using a full path:
tell application "Full:Path:To:MidiPipe.app" --(probably "YourHDName:Applications:MidiPipe.app"?
2) using an actual tell block:
tell application "MidiPipe"--or full path
activate
end tell
3) using the Finder:
tell application "Finder" to open "Full:Path:To:MidiPipe.app"
4) using shell:
do shell script "open /Applications/MidiPipe.app"
?

After looking at the links in CRGreen's answer, it looks like this is likely being caused by the process table being full on the mini. This, in turn, prevents any new applications from opening. According to The X Lab:
Error -10810 is a Launch Services result code indicating an unknown error. One cause of this error is that the MacĀ® OS X process table is full. When the process table is full, new (not currently running) applications cannot be opened until another running application ends. Programming errors in third-party applications can fill-up the process table, leading to the -10810 error when opening an application.
I would start by restarting the mini to see if that clears the process table, allowing you to to start MidiPipe.
If that doesn't work, you should look at your Activity Monitor to see if there is a specific program filling up your process table.

Could be nothing more than another mysterious grieving crap from Apple.
Today I have faced this myself, first time after using four different Mac Minis as build servers for Continuous Integration of Mobile apps for about two years or so.
My Jenkins runs the osascript from the bash script to build the app.
A few days ago the office experienced the power outage and all Macs went down. After powering them back on I have got this error at osascript execution on one of my Macs.
I have tried just to re-build - with the same result.
First thing I stumbled upon was https://jacobsalmela.com/2014/08/04/infamous-execution-error-error-type-10810-occurred-10810/ , but none of them applied to me.
Then I googled more general 10810 issue occurrences and went through couple of questions here on SO.
Still no luck.
Next I reached to the server via SSH using PuTTY and tried telling Terminal to do the very basic script like
osascript -e 'tell application "Terminal"
activate
tell window 1
do script "counter=0; while true; do if [ \"$counter\" -gt \"10\" ]; then
break; else counter=$((counter + 1)); sleep 1; fi; done; exit;"
end tell
end tell'
This worked fine.
Then I tried to run the whole bash script that Jenkins used to execute. Everything went just perfect and the app was uploaded to HockeyApp as the result.
I came with the thought that the issue is that Jenkins runs it remotely on that Mac and finally I have tried just to re-build again and it magically worked fine this time.
No idea what it was, but since then I have performed three or more builds already and all of them were successful.
Note I haven't changed anything, and my script:
1) never used a full path;
2) always used an actual tell block;
3,4) nothing like that from the accepted answer was ever used.
So... Go away mysterious grieving crap! Go away! :)

Related

Prevent or clear app state persistence for MacOS SwiftUI Document Based App

I am developing a MacOS Document based app using SwitfUI on MacOS 12.0.1 using Xcode 13.1 on a MacbookPro M1 Pro. I am encountering an issue that the app is always re-opening the document browser at the last used directory. Which is OK when it is on the Machine but a pain if the last used was on a network drive. I am trying to find a way of suppressing this "always restore using the last directory" mode of operation.
I have tried using the #NSApplicationDelegateAdaptor approach and implementing;
func applicationSupportsSecureRestorableState(_ app: NSApplication) -> Bool {
print(#function + " returning false")
return false
}
within my NSApplicationDelegate class, which does get called (although it seems sometimes after the dialog is presented), however this does not stop the app secretly remembering the last directory.
Does any know where this information might be being hidden or if it can be suppressed ?
I have looked for, but cannot find, a way of injecting a starting directory into a DocumentGroup as a possible solution.
TIA Alan.
Ok, for anyone who ends up here looking for a similar issue.
After a chunk of digging I found the answer, for me, was to add
UserDefaults.standard.removeObject(forKey: "NSNavLastRootDirectory")
into the app startup. It was also suggested to do
UserDefaults.standard.removeObject(forKey: "NSNavLastCurrentDirectory")
However, just doing the first appears to suppress the file open dialog, doing both causes the file open dialog to open with the user Documents directory.

Debugging on an end-user PC?

A user that works in my company has an Error 13 Type mismatch in the moment that she wants to input some data in a grid.
The thing is that when she has that problem, my application only shows the error screen and nothing more (I mean it doesn't say where the error occurs).
I want to know if there is a way that I can "see" the problem in a debug application because I don't have the source code of my application in this computer and I don't know if the problem is because of a Windows configuration issue or why this error pops up provided that when she uses another terminal, different to the one that she normally uses, she can do her job without problems (they have the same settings in the two pcs).
I have the source code in my terminal but as say above, in my terminal the error doesn't pop up so I need to see it in her terminal.
How can I do this?

Cocos desktop app can not access to files on MacOS

I have an application with the following structure:
./Data/test.txt
./TestMacOSApp
So my TestMacOSApp opens ./Data/test.txt and uses the content of test.txt. This app was working for a long time either on my MacBook or others MacBook. Recently I noticed that the app works on my MacBook fine,
but on others it crashes throwing "File is not found exception".
I create TestMacOSApp using XCode v9.1.
MacOS version is 10.12.6.
The App creation steps are Archive->Export->ExportApp (Without re-signing).
Does someone else have such an issue?
How can I solve this issue?
I don't know how you open the file because you didn't provide the code which does this.
But I know that, when you export your app on other computers, it is important to calculate the real path with fullPathForFilename, instead of giving directly the path that you know. Like this:
auto fileUtils = FileUtils::getInstance();
string content = fileUtils->getStringFromFile(fileUtils->fullPathForFilename(filename));
Have you done this? If you have, and it doesn't work, your file is probably just not where you expect it to be, so please check again.

Getting NSContactsUsageDescription to work in 10.8.2

I have an app with a crash reporter that autofills in the user email address by getting it from ABAddressBook. I'm trying to get an informative message of intent in the dialog that 10.8 displays asking the user for permission. Following the advice at http://www.red-sweater.com/blog/2672/can-i-get-your-address , I've added the following to the app's Info.plist:
<key>NSContactsUsageDescription</key>
<string>blah blah blah</string>
Unfortunately, this is not working. The dialog still asks, but it does not display my description text. I've tried:
Putting this in the crash reporter framework's Info.plist instead of the app's.
Signing the app with my Developer ID cert.
But, alas, no luck. Anyone gotten this to work that can give me a tip as to what I'm doing wrong?
[UPDATE] I found the real reason why restarting helps. It kills the tccd process, which looks like the culprit in charge of displaying the message on that dialog.
So, just open Activity Monitor and kill the tccd process and your new message should just show up next time the dialog shows.
[Old Answer]
I was running into the same problem and wasn't really sure why (I was doing exactly what the documentation said to do). I finally got it working after:
Deleting the container my app was living in (~/Library/Containers/com.company-name.app-name)
Cleaning the build (In Xcode: Product -> Clean)
Restarting my machine (seems a little cargo-cultish, but I think this is what fixed the problem)
Building and running my app
The next time my app tried to access the Address Book API I was presented with the dialog that included my message.
I think Apple must be caching that message somewhere (either the message you want, or an empty string if you ran your code before you had a message to show), and the only way to clear it out is to restart. I tried the first 2 steps many times with no change in the message, even after I got the message working and then tried to change it.
Solution is to run this command in the Terminal:
tccutil reset AddressBook
Source: https://developer.apple.com/library/archive/qa/qa1906/_index.html

Clipboard appears not to be working, and is inaccessible from code or windows

My clipboard seems to be 'stuck' - after some time of usage of my machine it simply stops working - any software trying to access it sticks or throws an exception on Ctrl + C or Ctrl + V. The problem persists when I try to access it through the .Net framework or Win32API (an exception is thrown - something like 'Clipboard unavailable' [sorry I couldn't copy-paste it here - my clipboard doesn't work! :)])
I keep on restarting all the time!
I'll appreciate any help or leads whatsoever, thank you:)
I have had seen a similar issue caused by an application which installed a clipboard changed hook (SetClipboardViewer) but later hung. Because it wasn't passing on WM_DRAWCLIPBOARD messages, eventually the clipboard simply stopped operating. Even Windows Explorer drag and drop stopped working.
I suggest that next time this happens to you, you go through all non-base-Windows applications and kill them off, one by one, until the clipboard starts working again. Perhaps use Process Explorer to make sure you're getting them all.
looks like the old SecuRom-bug. There is a fix for that on their website.

Resources