Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Any way to force focus shift?

edited November 2007 in FastScripts
I'm guessing that this is a side-effect of FastScript's Smart Switching.

I've got some scripts for EagleFiler that I execute from FastScripts Lite. For certain actions, EagleFiler will ignore scripted commands if you're currently editing the same item in the UI. For most ways of triggering scripts, this is a non-issue, since they take the focus off these fields. However, since FastScripts doesn't take the focus, these fields don't get updated. I'm wondering if you've got any suggestions for working around this at a scripting level (activating Finder then re-activating EagleFiler would probably work, but seems like a rather big hammer).

I've already asked Michael about what was going on and he explained to me why EagleFiler operates this way. From his explanation, the effort needed to change this behavior would far outweigh the benefit to resolving this edge case, so I'm looking for ways to fix it at my end.


  • Hmm - you could try manually activating FastScripts itself. FastScripts will only switch back from being active after it dismisses a dialog or finishes running the script. I think.

    Give it a try and let me know. It's almost as skanky as activating the Finder and switching back, but at least with FastScripts you shouldn't see any visual glitch.
  • From a scripting standpoint, it works, but there is a visual glitch. I'll discuss this one with Michael. Thanks.

    After posting the question, I thought it might be possible to work around this via UI Scripting. I'll have to look into that as well.
  • The visual glitch went away by sending an activate message to EagleFiler at the completion of the script.

    Now that I've looked at it, I'm wondering if FastScripts Lite was actually switching back automatically. The menu bar reflected EagleFiler as the frontmost app, but all the menu items were disabled, as was EagleFiler's main window.
  • Hmm - now that I think of it, if you manually activate another application I think FastScripts assumes that you wanted to do that as part of the script, so it doesn't do any "switch back" magic.
  • Just another followup - I translated my test AppleScript to Ruby (via rb-appscript), which I'm using for one of these problematic scripts. In this case, activating FastScripts Lite doesn't work because it appears that rb-appscript only works with applications that have scripting dictionaries. As a workaround, I'm instead activating System Events, since it's another faceless application.
  • Hmm - well, I'm curious about the specifics of why rb-appscript won't work with FastScripts. After all, FastScripts *does* have a scripting dictionary. At least it should. Maybe I left it out of the Lite version by mistake?
  • Actually, looks like it's there. I was able to open the dictionary in ScriptEditor. I'll look into this a bit more later.
  • Looks like a problem in rb-appscript - whenever I try to use app object for the app running the scripts, I get the following error:
    Message: /usr/local/lib/ruby/gems/1.8/gems/rb-appscript-0.4.0/lib/_appscript/terminology.rb:355:in `aetes_for_app': Can't get terminology for application (AEM::Application.by_path("/Applications/Utilities/FastScripts")): CommandError (RuntimeError)
    OSERROR: -609
    MESSAGE: Connection is invalid. from /usr/local/lib/ruby/gems/1.8/gems/rb-appscript-0.4.0/lib/_appscript/terminology.rb:366:in `tables_for_app'
    I originally interpreted this message as meaning there was no scripting dictionary. Sorry 'bout that.

    I've seen this both with running the aforementioned script via FastScripts and running test scripts in BBEdit.
  • Here's the email I got from Hamish Sanderson, rb-appscript's developer:
    Did this error appear after a minute's delay? If so, it's actually a timeout error [1], which would indicate a deadlock between the application, which is waiting for the script to finish before it handles the next event, and the script, which needs the application to respond to the events it's sending before it can finish. Your options are:

    1. Have your menu-triggered script start a new process that does all the actual work, allowing the menu script to return straight-away so that FastScripts can handle subsequent events.

    2. Use an OSA language component which can send events internally via the OSA API (I assume FastScript supports AppleScript/OSA-based menu scripts, yes?), thereby bypassing the host's event loop and thus avoiding a deadlock.

    Unfortunately there isn't a full-featured OSA component available for Ruby yet (writing one is on my TODO list once I finish my Python component [2], but it'll be a while yet), so #2 is a bit of a non-starter and you'll have to go with #1 for now.

    You might also contact the FastScripts author describing the deadlocking problem and see if they're willing to provide a solution at their end (feel free to point them in my direction if they need to discuss further; I've been through this with a couple other developers already and can probably dig up the relevant messages for reference).



    [1] For some reason appscript currently gets the wrong error code back from the Apple Event Manager when timeouts happen; they should raise error -1712, not -609. For now, assume error -609 can mean either a timeout has occurred or the application has quit.

    [2] See PyOSA <<a rel="nofollow" target="_blank" href="">>. It's a developer release so the usual caveats apply, but it's mostly usable with care - see its documentation for details.
    If you want to reach him, his email is hengist.podd at
  • Thanks - I will look into this sometime next week. I appreciate your doing the legwork with Has and figuring out what the problem is based in.
  • Thanks again - I followed up with has and we'll see if he has some good suggestions for how FastScripts could be handling this better.

Sign In or Register to comment.