Yosemite display dialog issue

Hi all,

I’m having some problems trying to make my dialog window come to the front in Yosemite. If I run the below script from the Editor the Script Editor comes to the front and my dialog is displayed in front of Safari. However if I save the script as an application and launch it, the application icon just bounce in the doc and the dialog does not become frontmost until I click on the application icon in the dock.

Has anybody else experienced this issue and know of a fix?

tell application "Safari"
	activate
	make new document
end tell

tell me to activate
display dialog "Stop"

Many Thanks,
Nik

You may use :

tell application "Safari"
	activate
	make new document
end tell

tell application "SystemUIServer"  to display dialog "Stop"

or

tell application "Safari"
	activate
	make new document
end tell

tell application "Safari"  to display dialog "Stop"

I know that both are violating the rule urging us to don’t call an OSAX feature in a tell application block but I don’t know an alternate scheme.

Yvan KOENIG (VALLAURIS, France) jeudi 4 décembre 2014 14:04:56

Hi Yvan,

Your first example works for me.

Thanks for your time,
Nik

What happens if you change


tell me to activate
display dialog "Stop"

to

tell me
	activate
	display dialog "Stop"
end tell

?

Same problem I’m afraid adayzdone but thanks for looking.

That only applies for user and any context of the osax command. Commands to run in the process context should be used in a tell block and will implicitly use the current application tell block when not defined. The user interaction section in the standard scripting addition are all commands using the process context and can be used in any tell application block.

do shell script, for example, does have the user context, which mean the command should be run by the current application and depends to user privileges. If I could run a do shell script by any process, I could run a shell command by telling the loginwindow process to execute a shell command. Because do shell script has a user context the event manager will ignore the command’s application context and send the command to the current application or to system events when the event is called over the network.

When the I run the first script, the events log is :

tell application "Safari"
	activate
	make new document
end tell
tell application "SystemUIServer"
	display dialog "Stop"
	«event ascrgdut»
	display dialog "Stop"
end tell

When I run the second one, the events log is :

tell application "Safari"
	activate
	make new document
	display dialog "Stop"
	«event ascrgdut»
	display dialog "Stop"
end tell

The double call to display dialog with the «event ascrgdut» item are part of what I get every time I trigger an OSAX command in a tell application block.
There is just a difference, I don’t get a non fatal error.
But it may be due to Yosemite because with this system, running :

tell application "Safari"
	current date
end tell

no longer issue a non fatal error.
The events log is now :

tell application "Safari"
	current date
end tell
tell current application
	current date
end tell

I would be interested to learn if the «event ascrgdut»
is issued in every system localisation or if it is dedicated to french one.
I know that I may force my system to English for see but I have too many tasks to achieve to do that.

If I run the script :

tell application "Safari"
	activate
	make new document
end tell

display dialog "Stop"

or the alternate

tell application "Safari"
	activate
	make new document
end tell
tell me
	display dialog "Stop"
end tell

The events log is :

tell application "Safari"
	activate
	make new document
end tell
tell application "Script Editor"
	display dialog "Stop"
end tell

Single call to display dialog, no «event ascrgdut»
but the dialog remains behind the new window.

Yvan KOENIG (VALLAURIS, France) jeudi 4 décembre 2014 16:49:57

«event ascrgdut» tells the AppleScript component to reload osaxen

Blend3,

What does the logging say when you have logging enabled. You can launch applications in the terminal, like your applet but when you set some variables first you can actually see what kind of events are send and replied back. However, since Mavericks the markup of the logging is more compressed, and worse readable if you ask me.

export AEDebugSends=1 export AEDebugReceives=1 application.app/Contents/MacOS/applet
When certain scripting addition have problems being loaded you will see here as well as all the events that are send and received and are connected to this shell are shown as well.

Note: Don’t start an application by using the ‘open’ command because the open command is using an AppleEvent («event GURLGURL») and the application is launched in another shell.

Hi DJ,

is the result you’re expecting to see?:

AE2000 (1121 ): Sending an event:
------oo start of event oo------
aevt('misc'\'actv' transactionID=0 returnID=4985 sourcePSN=[0x0,7c07c "Safari"] timeout=7200 eventSource=3 { &'subj':null(), &'csig':magn(65536) })
------oo  end of event  oo------
AE2000 (1121: Received an event reply:
------oo start of event oo------
aevt('aevt'\'ansr' transactionID=0 returnID=4985 sourcePSN=[0x0,7c07c "Safari"] timeout=0 eventSource=3 sourceUID=501 sourceGID=20 sourceEUID=501 sourceEGID=20 sourcePID=1081 auditToken=[501,501,20,501,20,1081,100006,1082]{  })
------oo  end of event  oo------
AE2000 (1121 ): Sending an event:
------oo start of event oo------
aevt('core'\'crel' transactionID=0 sourcePSN=[0x0,7c07c "Safari"] timeout=7200 eventSource=3 { 'kocl':type('docu'), &'subj':null(), &'csig':magn(65536) })
------oo  end of event  oo------
AE2000 (1121: Received an event reply:
------oo start of event oo------
aevt('aevt'\'ansr' transactionID=0 sourcePSN=[0x0,7c07c "Safari"] timeout=0 eventSource=3 sourceUID=501 sourceGID=20 sourceEUID=501 sourceEGID=20 sourcePID=1081 auditToken=[501,501,20,501,20,1081,100006,1082]{ '----':obj ('obj '{ 'from':null(), 'want':type('docu'), 'form':enum('name'), 'seld':utxt('utxt'(TEXT("Favorites"))) }) })
------oo  end of event  oo------
AE2000 (1121 ): Sending an event:
------oo start of event oo------
aevt('misc'\'actv' transactionID=0 sourcePSN=[0x0,2 "Untitled"] timeout=7200 eventSource=3 { &'subj':null(), &'csig':magn(65536) })
------oo  end of event  oo------
AE2000 (1121: Reply of SendToSelf ( err == 0):
------oo start of event oo------
aevt('aevt'\'ansr' transactionID=0 sourcePSN=[0x0,2 "Untitled"] timeout=0 eventSource=3 {  })
------oo  end of event  oo------
AE2000 (1121 ): Sending an event:
------oo start of event oo------
aevt('syso'\'dlog' transactionID=0 returnID=19016 sourcePSN=[0x0,2 "Untitled"] timeout=7200 eventSource=3 { '----':utxt('utxt'(TEXT("Stop"))), &'subj':null(), &'csig':magn(65536) })
------oo  end of event  oo------
AE2000 (1121: Received an event:
------oo start of event oo------
aevt('aevt'\'rapp' transactionID=0 returnID=12152 sourcePSN=[0x0,7007 "Dock"] timeout=60 eventSource=3 sourceUID=501 sourceGID=20 sourceEUID=501 sourceEGID=20 sourcePID=184 auditToken=[501,501,20,501,20,184,100006,185]{ ~'frnt':bool(0), 'disp':magn(69673152) })
------oo  end of event  oo------
AE2000 (1121: Reply of SendToSelf ( err == 0):
------oo start of event oo------
aevt('aevt'\'ansr' transactionID=0 returnID=19016 sourcePSN=[0x0,2 "Untitled"] timeout=0 eventSource=3 { '----':reco({ 'bhit':utxt('utxt'(TEXT("OK"))) }) })
------oo  end of event  oo------
AE2000 (1121 ): Sending an event:
------oo start of event oo------
aevt('aevt'\'quit' transactionID=0 returnID=11495 sourcePSN='kpid'[pid=1121 "Untitled"] timeout=0 eventSource=3 {  })
------oo  end of event  oo------
AE2000 (1121 ): Sending an event:
------oo start of event oo------
aevt('aevt'\'quit' transactionID=0 returnID=27438 sourcePSN='kpid'[pid=1121 "Untitled"] timeout=0 eventSource=3 {  })
------oo  end of event  oo------
AE2000 (1121 ): Sending an event:
------oo start of event oo------
aevt('aevt'\'quit' transactionID=0 sourcePSN='kpid'[pid=1121 "Untitled"] timeout=0 eventSource=3 {  })
------oo  end of event  oo------

Thanks,
Nik

Hello Stefan

Why is it called issued when the osaxen’s feature is called in a tell application block but is not called when the feature is called outside such a block ?

My understanding is that calling it from a tell application block is bad practice.

Yvan KOENIG (VALLAURIS, France) vendredi 5 décembre 2014 09:10:28

Apple explains the behavior a bit in the 10.6 AppleScript release notes

AppleScript Release Notes: 10.6 Changes

Hello Stefan

I knew this document.
It explains the double send but my old eyes see nothing explaining the osaxen reload («event ascrgdut»)

I made an attempt after setting the language to English and got the same behavior.

tell application “Safari”
display dialog “bof”
«event ascrgdut»
display dialog “bof”
end tell

When I re-run the script, the reload doesn’t behave.
If I close the editor then reopen it, «event ascrgdut» doesn’t appear.
The next time I will boot, I will make an other attempt with


display dialog "bof 1"
tell application "Safari"
display dialog "bof 2"
end tell

I’m wondering if in this case «event ascrgdut» will appear.

Yvan KOENIG (VALLAURIS, France) vendredi 5 décembre 2014 11:59:31

At first there isn’t much wrong with the events send. On my machine the kAEReopenApplication (rapp) event is not send to the Dock but for the rest it is the same. But I don’t think this is the issue because the kAEReopenApplication event is not send between activate and display dialog commands. Just a difference in OS (Currently not on a Yosemite machine).

So to make sure everything is done the same way you (or we) need to compare the results posted above with the results from ScriptEditor. Like you have launched the applet you can launch SE with the terminal after you set the AppleEvent debugger flags to 1. I’m curious about the difference in log from SE and your applet, if any.

Hello

I retrieved an events log returned under Mavericks.
The script was :

tell application "Mail"
	activate
	display dialog "x"
end tell
tell application "Safari"
	activate
	display dialog "x"
end tell
tell application "TextEdit"
	activate
	display dialog "x"
end tell

The event log was :

tell application "Mail" 
activate 
display dialog "x" 
--> error number -1708 
«event ascrgdut» 
--> error number -1708 
display dialog "x" 
--> {button returned:"OK"} 
end tell 
tell application "Safari" 
activate 
display dialog "x" 
--> error number -1708 
«event ascrgdut» 
--> error number -1708 
display dialog "x" 
--> {button returned:"OK"} 
end tell 
tell application "TextEdit" 
activate 
display dialog "x" 
--> error number -1708 
«event ascrgdut» 
--> error number -1708 
display dialog "x" 
--> {button returned:"OK"} 
end tell

When I ran the same script under Yosemite (10.10.1) the events log was :

tell application "Mail"
	activate
	display dialog "x"
	«event ascrgdut»
	display dialog "x"
end tell
tell application "Safari"
	activate
	display dialog "x"
end tell
tell application "TextEdit"
	activate
	display dialog "x"
	«event ascrgdut»
	display dialog "x"
end tell

As I already wrote, in Yosemite the non fatal error number -1708 doesn’t strike (or at least, it’s not reported).

I am really puzzled by the «event ascrgdut»

OK, it’s supposed to reload the osax Standard Additions when display dialog is called in the tell application “Mail” block.
OK, I may imagine that the osax is already loaded when the script calls display dialog in the tell application “Safari” block.
But, why is it asked to reload when display dialog is called in the tell application Textedit block ?

For my poor brain, it’s really puzzling because when I ran the same script five minutes later, the events log was :

tell application "Mail"
	activate
	display dialog "x"
end tell
tell application "Safari"
	activate
	display dialog "x"
end tell
tell application "TextEdit"
	activate
	display dialog "x"
end tell

which make me think that the osax remained available in memory after the reload issued in the tell application TextEdit block and let a question without a response : why was it necessary to reload it the first time I ran the script ?

I know that some of you will think that I am mistreating the flies but I am curious and I like to understand what apply when I use a tool.

Yvan KOENIG (VALLAURIS, France) vendredi 5 décembre 2014 14:47:03

I wouldn’t care about automatically sent “low level” events as long as the environment behaves as expected