Please send it to me.
For anyone following along, there are some important things to keep in mind:
-
Enhanced Applets run their scripts on a background thread. If you are using ASObjC, any code that deals with interface items needs to be run on the main thread, using
performSelectorOnMainThread:withObject:waitUntilDone:. -
Whenever signing code, you should always check the results before distributing your app. In Terminal:
/usr/sbin/spctl --assess --type exec -vv /path/to/Your.app
The result needs to say accepted and source=Developer ID.
It’s also worth keeping in mind that the signing done by Script Debugger and Script Editor is not adequate for notarizing.
1 Like
Thanks again. Shane! I think the signing issue was related to me being behind a coporate firewall saving and the response timing out or being blocked. It locked up Script Debugger a few times. Verifying is definately key and tip helpful!
The main thread vs the background thread issue seems more sensitive in 7.08 then it was in 7.06. I tried running the older version to test my theory but it wouldnt run since the new release is on my machine…although I agree I was definately pushing the background thread UI boundaries. Can you give me an example of usage of performSelectorOnMainThread:withObject:waitUntilDone: in a subroutine? Its tough to find an example of use. I found an old reference to one on your site but the post was outdated.
As always your knowledge is appreciated.
The issue is not directly related to the version of Script Debugger — it’s the OS. Dealing with interface stuff on background threads has always been illegal, but some infractions used to be ignored, then they started producing console errors, and now they’re throwing full-blown exceptions.
You should find plenty of examples around here. You’re using Dialog Plus Toolkit in your app, so look at its code — it uses it extensively.
Doh! Found it just as your responded. Perfect examples in Dialog Toolkit.
Shane,
With the current version of any Enhanced App I save, if I view the typical About window, it shows it then unexpectedly quits after closing the window. This is the same behavior I am experiencing with any UI, although I broke the rules of background threading and main threading and have since fixed it, I still get the same behavior. Can you confirm if you experience the same issue as an enhanced app set to always keep open? It only started in the most recent release.
Thanks
Dean
Email me an example.
It looks like there’s a bug. Until it’s fixed, you can disable the About… menu item like this:
set aboutMenu to (current application's NSApp's mainMenu()'s itemAtIndex:0)'s submenu()'s itemAtIndex:0
aboutMenu's setAction:(missing value)
Is there a way to run the older debugger version? It happens with any ui interaction even if I’m background thread or updates etc
The Script Debugger 7.0.7 release announcement contains a direct download link:
It goes to the 7.08 page. I have version 7.06 however when I try running it it says my version timed out and to run the latest version. Is there a way to over-ride that or can you send me a beta version of 7.07 that will run?
it says this if I try running any older version I have:
The build of Script Debugger has expired. Contact support@latenightsw.com if you have not already received a notification of a newer build.
Sorry the reason I need this is I use the sparkle update and I am saving out a current version of my enhanced applet and any dialog or ui call causes it to quit if I am using your last release and on client-site otherwise I would be patient until the fix is released.
Hey guys…wanted to thank you. The 7.07 version works great as enhanced applet. It helped out in a pinch. Feel free to send beta update when you have time to resolve the bug.
Shane,
Is there a chance you or @alldritt could look at what the differences between 7.07 and the newer versions of Script Debugger causing this bug? I hate having to keep using the older version even for saving. Just a reminder…saving as enhanced app and using update/about menu causes app to quit unexpectedly.
Are you able to move this to new topic? Or should I create a new one?
I’m not sure what’s happening there. I just opened a new document (from the Enhanced Applet template), saved it, ran it, opened the About menu, closed it again, without any crash.
It seems related to status bar item. Here is an example that quits when you save as enhanced and goto the about menu.
use AppleScript version "2.4"
use scripting additions
use framework "Foundation"
use framework "AppKit"
property NSStatusBar : a reference to current application's NSStatusBar
property NSVariableStatusItemLength : a reference to current application's NSVariableStatusItemLength
property NSMenu : a reference to current application's NSMenu
property NSMenuItem : a reference to current application's NSMenuItem
property theStatusItem : missing value
set theList to {"Fruit", {"Apple", "Banana"}, "Vegetable", {"Lettuce", "Tomato", {"Fresh", "Salty"}}, "", "Quit"}
my performSelectorOnMainThread:"menuBarTest:" withObject:(current application's NSVariableStatusItemLength) waitUntilDone:true
theStatusItem's setTitle:"Food"
theStatusItem's setHighlightMode:true
set aMenu to NSMenu's alloc()'s init()
set {aCount, prevMenuItem} to {10, ""}
makeNewSubMenu(theList, aCount, aMenu)
theStatusItem's setMenu:aMenu
on makeNewSubMenu(aList, aCount, aMenu)
repeat with i in aList
set j to contents of i
if j is equal to "" then
set aMenuItem to (NSMenuItem's separatorItem())
(aMenu's addItem:aMenuItem)
else if ((class of j) as string) = "list" then
--Generate Submenu
set subMenu to NSMenu's new()
(aMenuItem's setSubmenu:subMenu)
my makeNewSubMenu(j, aCount, subMenu)
else
set aMenuItem to (NSMenuItem's alloc()'s initWithTitle:j action:"actionHandler:" keyEquivalent:"")
(aMenuItem's setTag:aCount)
(aMenuItem's setTarget:me)
(aMenu's addItem:aMenuItem)
set aCount to aCount + 10
copy aMenuItem to prevMenuItem
end if
end repeat
end makeNewSubMenu
on actionHandler:sender
set theTag to tag of sender as integer
set theTitle to title of sender as string
if theTitle is not equal to "Quit" then
display dialog (theTag as string) & " " & theTitle as string
else
NSStatusBar's systemStatusBar()'s removeStatusItem:theStatusItem
quit
end if
end actionHandler:
on menubarTest:theObject
set theStatusItem to (current application's NSStatusBar's systemStatusBar()'s statusItemWithLength:(theObject))
---return theStatusItem
end menubarTest:It works fine here. Can you email me the file you’re testing?
I just sent. Thank you!
Were you able to reproduce? Can anyone else here test the code posted above and goto about menu and see if theirs quits when closing the window?
Yes, I can reproduce it, thanks.