Strange error from 'do shell script' in a try block within a tell one

Display dialog is an ‘odd’ command. For normal commands in a tell application block an event is send to the current target application. When the application can’t/doesn’t want to handle the event it is send to the parent (following the parenting chain). For a display dialog the command is send immediately to the system and a dialog is displayed in the target application context. Similar to commands like activate.

Hello!

I think the display dialog is to be handled by SystemUIServer so I use a construct like this, I think it also speed up things a little!


tell application "SystemUIServer"
	activate
	display dialog "Testing"
end tell

I use to have try error block in there, but then I set a failed variable to true, and deals with the error outside the context of SystemUIServer, if the script is to quit, etc.

I think such an approach is wise, also for other tell blocks, as to not have events “pending” inside running applications.

Thanks guys,

I’ll use this construct in my current attempt to optimise a longer script for speed.

Regarding speed, could you point me to options to actually time the execution of a script between dialogs precisely. I haven’t done actual measurements yet, other than rough manual timing.

Cheers,
Chris

Hello!

I don’t think that displaying dialogs that way will speed up your script much, but you will direct the events directly to where they’ll end up anyway. And you can be pretty sure that the dialog will turn up, whatever space or screen you are in, it will be visible, and rendered fast, since it is SystemUIServer that takes care of such things, and no pending events on the way, in for instance a busy finder, or busy SystemEvents, or whatever app you are using will slow it down.

Look Here! post #1 and post #14 for timing tools.

Edit I see below that there are diverging opinons about this matter, but I’ll stick to my way, as I am happy with it. I think I have experienced that the display dialogs can be slowed down, at least when addressed through System Events, or Finder.

Like i said in my previous post, display dialog doesn’t follow the parenting chain like normal events do, so there are no ‘events pending’. The event is sent immediately to the window server, not to systemUIServer, and display dialog for current application, finder or any other application shouldn’t have any measurable time differences.

Hello!

One thought has struck me: what if SystemUIServer is just another synonym for Window Server?

And I’d really love to see a log of the aetes travelling to the windowserver in both cases, to see if there are any difference! :slight_smile:

I’ll come back to this subject, as I want to perform some other kind of tests, regarding localization, to see what kind of information is displayed, when calling display dialog through different applications.

Hello!

When I tell Finder, SystemUiServer, or System Events to display a dialog, I get the buttons localized in my lingo. When I tell BBEdit to display dialog, then I get it in english. I can hardly interpret that in any other way, than that something more happens, than merely passing it over to the window server.

Window Server = WindowServer process including Quartz Compositor in it
SystemUIServer = the server for the menu at the top right corner of your screen.

Hello!

I see! Well, I actually read in the book Applescript the missing manual :smiley: that routing it through “SystemUIServer” was the fastest way. I have gotten complaints here, about routing the calls to display dialog through System Events.

And as I pointed out, there is a difference in the way the display dialog is localized, when calling it from BBEdit, than in the other cases.

I don’t know what to believe really, until someone drags up a reference to some documentation, or shows me a dump of the aete traffic.

Hi Again! :smiley:

There is no magic whatsoever: Show a dialog (with another process than SystemUIServer) and kill SystemUIServer and see what happens; the dialog remains and top menu will dissappear. Not recommended but look what happens if you kill WindowServer… aqua will die

Hello!

I figured it all out! Before Coffee! Maybe SystemUIServer, is the app with the smallest dictionary for one thing, so the least overhead in resolving a tell block for a target application for AS is to call SystemUIServer.

That display dialog is implemented in Standard Additons.osax is a fact! But there are data passed along as well, from the current application, as my test with BBEdit showed.

I don’t want to kill my window server right now. I take your word for it! But the dialog, is killed when I kill SystemUIServer!

The one thing I seem to disagree with you about at this moment, is that data is passed a long, before calling Standard Additions.Osax directly, avoiding the parent chain. But that was never mentioned really.

Dictionary size doesn’t matter at all, because terminology is resolved at compile time.

Hello Stefan! :slight_smile:

( Unless you are using terms from. But that isn’t the question here. )

How sloppy of me! Well Stefan is there any rational reason for having the display dialog in a tell “SystemUIServer” block to invoke the display dialog as fast as possible?

I 'm thinking that maybe the aetes sent to SystemUIServer, either has higher priority, or that SystemUIServer, is running all the time, so it is latent in memory, and faster to call, and even given priority when it comes to memory as it deals with pages of it, in the user interface. That such factors may make it a faster renderer of display dialogs, as the over all process goes quicker with it run time.

Not even then. Terminology will only be resolved at runtime with a run script command.

Not for me because the reaction of the user is always much slower :wink:

Hello!

I see, At least I believe, that the process being adressed in a tell block, is addressed in some way; that even if no resources of the targeted app is used, ( I am talking about applications targeted by tell blocks only), a process of sending applevents are started. And the time for this communication channel to be established, would be dependent of the process status in real memory (by real memory, I mean active physical memory). I believe SystemUIServer to always be in physical memory, since it is about updating the UI. Therefore I believe SystemUIServer to be the fastest. Being the process that it is fastest to establish contact with, and therefore the fastest to delegate the display dialog request away to Standard Addtions.Osax. Even faster than the current application, as the current application may (theoretically) need to load some pages into real memory first.

Having pondered this, I think this hack, was established some years ago, when having less than a gig of memory was the norm! :slight_smile:

But, say if the system is bogged down with some serious downloading, and updating spotlight meta data, while the macports ports tree is updated, (rebuilt), under such conditions, I think it to be noticable.

True! :slight_smile:

consider that current application is NOT the frontmost application but the current AppleScript runner environment

Hello!

That is really something to consider! To be honest, I couldn’t find Apple Script Runner when using the ps utility to check out the priority, but SystemUIServer, has the standard priority of an application 48, so there is nothing special there. But the process is small! It takes up only 17.2 Mb of physical memory.

As I can’t stat AppleScript runner, or doesn’t know how to, I’ll continue using SystemUIServer

I said don’t show a dialog with systemUIServer. When I show a dialog with the Finder and kill it, the dialog is gone as well. But when I show a dialog in the Finder and kill systemUIServer the dialog stays on my screen and the upper right menu is gone (except for spotlight). The window server (where every application is, must, connected to) notice if an process/application lost connection with it or died. When an application died there is no use still showing objects for it so the window server removes those objects, that’s the reason why the dialog is gone. This simple test proofs that dialogs aren’t handled by systemUIServer but are handled directly by the window server.

Hello!

I figured out that along the way!

There is some points here though, one of them being, that there are some kind of communication, between the app, and the window server, in the form of aete events.

What’s next, I am not sure, or can’t explain. But what you have from before inflicts on the speed of the scripting component. (Otherwise there wouldn’t be any gain in run script from within a run handler, this is proven to be faster, because then Scripting Addtions takes over the IPC (inter process communication), which it does faster than the original scripting component of an applet).

I want to make a point of that I am not just stubborn here! :smiley:

And, there is no real reason for using the SystemUIServer to speed up the display of the display dialog, I believe it to be the context change, (memory wise) to a smaller app, with a smaller footprint, with no pending aetes that makes up any difference, if any, which I really can’t stat. Maybe it is a one way communication with the SystemUIServer through aetes But, having said that, I still believe it to make a difference on a machine with a heavy load.

I’m sorry I had to go to this extent, to bring the facts on the table.

I am still going to use this way of displaying dialogs, since ı believe in it! :smiley:

I was interested in the advice given by user @McUsr about the possibility of using the SystemUIServer.app to stably display dialog inside the tell-block of other applications.

I decided to put his advice to a harder test. I was wondering if the SystemUIServer would be able to display a dialog even when there is nothing on the screen other than the full window of another application (full screen mode).

Test result: the hack works in this case too!.

It would be interesting to know if there is at least one example when this does not work

Here is my test script that you can repeat:


tell application "Finder"
	display dialog "I am Finder dialog"
end tell

tell application "Skim"
	tell application "SystemUIServer" to display dialog "I am Skim dialog"
	set interaction mode of document 1 to full screen mode
end tell

tell application "Finder"
	tell application "SystemUIServer" to display dialog "I am Finder dialog, again"
end tell

tell application "Skim"
	tell application "SystemUIServer" to display dialog "I am Skim dialog, again"
end tell

NOTE: as I checked, for do shell script command inside tell blocks of applications, instead of tell current application works stably tell me and tell AppleScript as well. At least, on the Catalina.