Any way to force focus shift?
  • Edit
    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.
  • Daniel JalkutDaniel Jalkut
    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.
  • JablairJablair
    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.
  • JablairJablair
    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.
  • Daniel JalkutDaniel Jalkut
    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.
  • JablairJablair
    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.
  • Daniel JalkutDaniel Jalkut
    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?
  • JablairJablair
    Actually, looks like it's there. I was able to open the dictionary in ScriptEditor. I'll look into this a bit more later.
  • JablairJablair
    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 Lite.app")): 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.
  • JablairJablair
    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).

    HTH

    has

    [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="http://appscript.sourceforge.net/pyosa.html">http://appscript.sourceforge.net/pyosa.html>. 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 virgin.net.
  • Daniel JalkutDaniel Jalkut
    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.
  • Daniel JalkutDaniel Jalkut
    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.

    Daniel
Add a Comment

Howdy, Stranger!

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

Sign In Apply for Membership

Categories