Enhanced applet issue quiting

(marshall) #1

For some reason if I save my applet as enhanced it never really quits using:

my |quit|:sender 

or

if (name of current application) is not "Script Debugger" then
    tell current application
        quit 
    end tell
end if

if I save it as a standard applet it quits normally.
The only reason I discovered the issue is I quit and re-opened it and the menus did not appear. When I resaved in script debugger it asked if I wanted to quit the applet and save.

Any idea why this is happening?

0 Likes

(marshall) #2

It is definately specific to Enhanced Applet. Related to another post: Continue quit not working in enhanced applet @ShaneStanley @alldritt Any suggestions how to work around this temporarily?

1 Like

(marshall) #3

I did find 2 temporary workarounds

seemingly the safer way:

set theApp to quoted form of "quit app \"Your App Name Here\""
do shell script "osascript -e " & theApp

or

do shell script "killall FancyDroplet"

the downside to this is it will kill all FancyDroplets running. Is there a way to rename the fancydroplet? I tried to do and change in info.plist without success.

1 Like

(Shane Stanley) #4

All you need is a simple:

quit

(Please wrap your code here in lines containing just three back-ticks, so it formats correctly.)

0 Likes

(marshall) #5

Thank you for the response. Unfortunately it doesnt work with quit. I think it has to do with being a menubar app and setting Application is agent to true. Quit works as applet but not enhanced applet. I tried on a few menubar app samples I found online. Not sure why this works though:

set theApp to quoted form of “quit app “Your App Name Here””
do shell script "osascript -e " & theApp

0 Likes

(Shane Stanley) #6

Can you email me an example?

0 Likes

(Mark Alldritt) #7

I’m having trouble reproducing this problem here. I’ve tried a few things:

  1. Quitting from the on run handler:

    set shouldQuit to button returned of (display alert "Shall I quit" buttons {"OK", "Cancel"} default button "OK") = "OK"
    
    if shouldQuit then
    	quit
    end if
    

    This works as expected, the applet quits.

  2. From an on idle handler:

    on idle
    	set shouldQuit to button returned of (display alert "Shall I quit" buttons {"OK", "Cancel"} default button "OK") = "OK"
    
    	if shouldQuit then
    		quit
    	end if
    	return 10
    end idle
    

I also tried replacing the bare quit command with the code you cite. but there is no difference:

if (name of current application) is not "Script Debugger" then
    tell current application
        quit 
    end tell
end if
0 Likes

(marshall) #9

I forwarded the example file to you.

0 Likes

(chris) #10

Sorry to reply here but I have the same issue
my app is quit perfectly when the process is Finnish but if I open the app and closed by the red button the app still open in the finder?

See image

0 Likes

(chris) #11

@dean
try this

tell application "Your app name"
    quit
end tell
0 Likes

(Ed Stockly) #12

If the enhanced app window is closed the app does not quit. There does not seem to be a way to react to the window being closed. If the user clicks close the window closes but reopens again if progress is used.

Also I’ve noticed sometimes the enhanced apps don’t act the same way standard apps do when finished executing. They remain open, with their icon in the dock, rather than quitting.

0 Likes

(Ed Stockly) #13

Here’s an example. Save this script as an enhanced app and as an Apple app.

In the enhanced version the quit menu halts the script. It doesn’t run, it can’t quit and must be forced quit. Clicking stop, or selecting Quit from the dock doesn’t work. Force quitting is the only thing that works. Adding a “tell me to quit” to the quit handler doesn’t help.

In the standard version the quit menu has no effect.

In the enhanced version clicking the close window button closes the window, but it opens again at the next Progress update.

In the standard app the close window button is inactive.

property progressRecord : {ProgressTotalSteps:-1, progressCompletedSteps:0, progressDescriptionText:"", progressAdditionalDescriptionText:""}

on run
   repeat with x from 1 to 20
      delay 1
      set ProgressTotalSteps of progressRecord to 20
      set progressCompletedSteps of progressRecord to x
      --set progressDescriptionText of progressRecord to ""
      --set progressAdditionalDescriptionText of progressRecord to ""
      my updateProgress()
      
      
   end repeat
end run
on quit
   continue quit
end quit
on updateProgress()
   -- {ProgressTotalSteps:-1, progressCompletedSteps:0, progressDescriptionText:"", progressAdditionalDescriptionText:""}
   tell progressRecord
      set totalSteps to its ProgressTotalSteps
      set completedSteps to its progressCompletedSteps
      set descriptionText to its progressDescriptionText
      set addDescriptionText to its progressAdditionalDescriptionText
   end tell
   set progress total steps to totalSteps
   set progress completed steps to completedSteps
   set progress description to descriptionText
   set progress additional description to addDescriptionText
end updateProgress

0 Likes

(Nicholas Riley) #15

I think this is happening to me too. The applet does seem to want to quit, but it gets stuck. Here’s a sample from where it’s stuck:

Call graph:
892 Thread_465459   DispatchQueue_1: com.apple.main-thread  (serial)
+ 892 start  (in libdyld.dylib) + 1  [0x7fff69a46ed9]
+   892 NSApplicationMain  (in AppKit) + 780  [0x7fff39d2e8a3]
+     892 -[NSApplication run]  (in AppKit) + 699  [0x7fff39d3f165]
+       892 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:]  (in AppKit) + 1362  [0x7fff39d45102]
+         892 _DPSNextEvent  (in AppKit) + 997  [0x7fff39d46363]
+           892 _BlockUntilNextEventMatchingListInModeWithFilter  (in HIToolbox) + 64  [0x7fff3ba8b568]
+             892 ReceiveNextEventCommon  (in HIToolbox) + 618  [0x7fff3ba8b7eb]
+               892 RunCurrentEventLoopInMode  (in HIToolbox) + 293  [0x7fff3ba8bab5]
+                 892 CFRunLoopRunSpecific  (in CoreFoundation) + 463  [0x7fff3c7f4c64]
+                   892 __CFRunLoopRun  (in CoreFoundation) + 2335  [0x7fff3c7f57d6]
+                     892 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__  (in CoreFoundation) + 9  [0x7fff3c7f60c7]
+                       892 _dispatch_main_queue_callback_4CF  (in libdispatch.dylib) + 1125  [0x7fff69a03f63]
+                         892 _dispatch_client_callout  (in libdispatch.dylib) + 8  [0x7fff699f8dcf]
+                           892 _dispatch_call_block_and_release  (in libdispatch.dylib) + 12  [0x7fff699f7d53]
+                             892 __73-[AppDelegate _respondToEventInBackground:completion:eventSuspendsionID:]_block_invoke_2  (in FancyDroplet) + 1062  [0x10e5dd4f9]
+                               892 -[NSApplication terminate:]  (in AppKit) + 765  [0x7fff39f4d95d]
+                                 892 -[NSApplication _shouldTerminate]  (in AppKit) + 1347  [0x7fff3a07cf73]
+                                   892 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:]  (in AppKit) + 1362  [0x7fff39d45102]
+                                     892 _DPSNextEvent  (in AppKit) + 997  [0x7fff39d46363]
+                                       892 _BlockUntilNextEventMatchingListInModeWithFilter  (in HIToolbox) + 64  [0x7fff3ba8b568]
+                                         892 ReceiveNextEventCommon  (in HIToolbox) + 618  [0x7fff3ba8b7eb]
+                                           892 RunCurrentEventLoopInMode  (in HIToolbox) + 293  [0x7fff3ba8bab5]
+                                             892 CFRunLoopRunSpecific  (in CoreFoundation) + 463  [0x7fff3c7f4c64]
+                                               892 __CFRunLoopRun  (in CoreFoundation) + 1654  [0x7fff3c7f552d]
+                                                 892 __CFRunLoopServiceMachPort  (in CoreFoundation) + 337  [0x7fff3c7f5fde]
+                                                   892 mach_msg  (in libsystem_kernel.dylib) + 60  [0x7fff69b806d0]
+                                                     892 mach_msg_trap  (in libsystem_kernel.dylib) + 10  [0x7fff69b8017a]
892 Thread_465512: com.apple.NSEventThread
+ 892 thread_start  (in libsystem_pthread.dylib) + 13  [0x7fff69c39415]
+   892 _pthread_start  (in libsystem_pthread.dylib) + 70  [0x7fff69c3d26f]
+     892 _pthread_body  (in libsystem_pthread.dylib) + 126  [0x7fff69c3a305]
+       892 _NSEventThread  (in AppKit) + 160  [0x7fff39d4ef89]
+         892 CFRunLoopRunSpecific  (in CoreFoundation) + 463  [0x7fff3c7f4c64]
+           892 __CFRunLoopRun  (in CoreFoundation) + 1654  [0x7fff3c7f552d]
+             892 __CFRunLoopServiceMachPort  (in CoreFoundation) + 337  [0x7fff3c7f5fde]
+               892 mach_msg  (in libsystem_kernel.dylib) + 60  [0x7fff69b806d0]
+                 892 mach_msg_trap  (in libsystem_kernel.dylib) + 10  [0x7fff69b8017a]
892 Thread_481679
  892 start_wqthread  (in libsystem_pthread.dylib) + 13  [0x7fff69c39405]
    892 _pthread_wqthread  (in libsystem_pthread.dylib) + 670  [0x7fff69c39710]
      892 __workq_kernreturn  (in libsystem_kernel.dylib) + 10  [0x7fff69b81b6a]

Happy to provide my applet source if it would be helpful. For now I’ll try to use one of the workarounds.

0 Likes

(Mark Alldritt) #16

We have improved the Enhanced Applet shell for the upcoming Script Debugger 7.0.8 maintenance release to address this issue. You can download a pre-release build here. Note that you’ll need to be part of our Beta Testing group to access this page - just PM me @alldritt to gain access.

1 Like

(Nicholas Riley) #17

FYI, just recompiling my applet with the 7.0.8 beta causes quitting to be 100% reliable for me on two Macs and several days’ use for now. I still needed to end my script with “tell me to quit”, however. Thanks!

0 Likes

(chris) #18

7.0.8 beta works here, no issue on quiting
Great work thanks you DEV! I am Waiting for the release
Edit** 01 April
Small issue
Wnen I closed About this utility the entire program closed?

0 Likes