• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Tell Blocks Considered Harmful (was Re: open for access)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Tell Blocks Considered Harmful (was Re: open for access)


  • Subject: Re: Tell Blocks Considered Harmful (was Re: open for access)
  • From: Chris Page <email@hidden>
  • Date: Tue, 16 Dec 2008 15:32:06 -0800

On Dec 16, 2008, at 12:18 PM, Paul Berkowitz wrote:

My main issue is being able to bring the dialog to the front via an activate ...

That is one issue. Whether the dialog is displayed in front of the frontmost application. It is separate from ...


... sometimes I want to have the relevant application (e.g. Entourage) visible behind and not let the user tinker with it until he dismissed he dialog.

... why do you want to prevent the user from interacting with Entourage? How critical is it to the correct operation of your script applet? What might go wrong if your applet doesn't prevent user interaction with Entourage?


I am trying to think if the same could be achieved, without loss of any function, by being able instead to specify (as an option) that the dialog be system-modal (floating above all windows).

Actually, there's such a thing as a "system modal" dialog. It prevents users from interacting with any application until you dismiss that dialog. They are rarely used.


It is also possible to have windows from a process float in front of the windows of all other processes without blocking user interaction. For example, the Help window in Leopard. It is displayed by an application that has no menu bar or Dock icon and the help window always remains frontmost.

So I need to know whether that would suffice or if you actually need ‘display alert’ to prevent user interaction with applications other than your applet.

I'm trying to think of a downside, but at the moment I don't see any, aside from the one mentioned by Ed that it would be awkward for new scripters to learn how to remove osax commands from within tell blocks.

I'm sorry, I don't quite know what you're responding to when you say “downside”. Downside to which suggestion?


I'm suggesting that, today, currently, scripters should try to keep tell blocks small and not unnecessarily place commands within them. They should do that now, with the language exists today.

I'm separately wondering whether it would be a problem if we changed (some or all) scripting addition commands to run within the script's process, effectively ignoring ‘tell’s. This would eliminate some of the reasons why I suggest people keep commands out of tell blocks.

The commands that display modal dialogs are perhaps the most obvious ones where it might be desirable for them to continue being sent to the ‘tell’ target, so I'm asking to find out whether it is critical or not to your scripts. Would it break your scripts, or would it only subtly change the behavior in a way that doesn't matter to people using your scripts?

(For myself, rather than 'tell me' I might get into the habit of calling a standard DisplayDialog(thePrompt, theButtons, ...) handler.)

I think that's a fine idea. However, to do that you still have to use ‘tell me’ or ‘my’ or ‘of me’ to have the function call sent to your script instead of the ‘tell’ target.


  on DisplayDialog(...)
     ...
  end

tell application "Finder"
...
tell me to DisplayDialog(...)
my DisplayDialog(...)
DisplayDialog(...) of me
-- the following is an error:
DisplayDialog(...) --> "Finder got an error: Can’t continue DisplayDialog."
end tell


I think that's got to be the main objection - the nuisance of common osax calls requiring laborious workarounds.

Which is why I'm wondering if we could change the behavior of additions commands so that they ignore the ‘tell’. Then you wouldn't have to change your scripts. But would it break your scripts? Which commands would pose a problem for your scripts?


Does it matter which application process handles the ‘beep’ command? Probably not. Does it matter where ‘open for access’ and ‘write’ are handled? Yes, it matters, especially from a security perspective. Does it matter where ‘display alert’ is handled? For some scripts, no. But are there some scripts for which it is critical for correct operation?

And, more importantly, is it critical only because they need to display the dialog in front, or is it critical because they need to block user interaction with applications other than the one running the script?

I think you'd need to bring all of Apple's own Standard Additions into the AppleScript language so that they "just work" and don't break a million existing scripts.

That's sort of what I'm suggesting. That they would ignore ‘tell’s and always be handled within the process running the script. But that may actually *break* some scripts. What I'm trying to determine here is which scripts that might break and which scripts would be fine. And the answer varies depending on which commands scripts are using within tell blocks and why they're doing so.


(Could this even be done for user-interactive commands such as display dialog?)

Yes, that's exactly what I'm asking.

--
Chris Page - AppleScripter

 The other, other AppleScript Chris

_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users

This email sent to email@hidden
References: 
 >Re: Tell Blocks Considered Harmful (was Re: open for access) (From: Paul Berkowitz <email@hidden>)

  • Prev by Date: Re: Tell Blocks Considered Harmful (was Re: open for access)
  • Next by Date: Re: Tell Blocks Considered Harmful (was Re: open for access)
  • Previous by thread: Re: Tell Blocks Considered Harmful (was Re: open for access)
  • Next by thread: Re: Tell Blocks Considered Harmful (was Re: open for access)
  • Index(es):
    • Date
    • Thread