HELP! AppleScript, Resource Fork, or Mac OS 9 Bug?

[BryMD]

Hey guys!

Been having some spare time the past couple of months during my paternity leave, and what better way to spend it than to make some brand new software for Mac OS 9? 

At the current moment I'm working on two utilities for Mac OS 9 written in AppleScript:
1. Functional Keys for adding sound, depth, resolution, and iTunes controls to the F-keys (attached to this post, as well as uploaded to here: http://macintoshgarden.org/apps/functional-keys/ ).
2. Seagull AutoPlay for adding screen saver-mode to Seagull Video Player 2.0.

Both are coming along nicely, but I've run into a couple of deal-breaking snags when it comes to Functional Keys:
1. The AppleScript applets insist on bringing Finder to the foreground whenever activated (even with 'only in background' enabled in the resource fork), reducing their practicality dramatically.
2. Furthermore, the applets refuse to run whenever an application is running full screen, making them close to useless.

At this point I'm SERIOUSLY out of ideas on whether the problem lies in the script, the resource fork or in the way AppleScript applications are executed on Mac OS 9. Apple's own Eject Extras (though not AppleScript applets I believe) do not carry any of these limitations, so it should be quite possible to crush these bugs.

Is there anyone here at Mac OS 9 Lives equipped with the right kind of bug spray who could share some with a desperate soul? 

[Astroman]

I don't have much experience in this scripting domain, but the reason may be simple:
It's an event driven system and the Finder may have a priviledged degree of attention, so it snatches the keyboard events on their way before they reach your script.
Imho that's not a bug but due to overall design of the scripting system, but I'm no expert.

[BryMD]

Hi Astroman!

Yes, Finder snatches the keyboard event as it should as Functional Keys use the built in F-key assigments in the Keyboard control panel in later revisions of Mac OS 9 for activation. However, when assigning Apple's own Eject Extras to the F-keys none of the afforementioned bugs exist, so I can't imagine the problem lies between the keyboard and the system. As such, I still believe these bugs lie in one of the 3 mentioned domains (script code, resource fork or AppleScript execution). Just hoping it's not the latter, as I then will have to either write a wrapper Application or rewrite Functional Keys in a different language.

Any other thoughts on where I should focus my attention?

[Daniel]

The problem appears to be that doing anything useful with the Finder brings it to the front as a side effect. The activate command specifically does this and many other things do it implicitly. The scripts are separate applications and do not bring Finder to the front if they don't ask the Finder to do anything.

 A partial solution would be to make the script hide Finder when it finishes (this might get annoying if you actually wanted the Finder to be active). I tried to figure out how to save the current active application (using the frontmost flag in the process class), but it appears that AppleScript doesn't let you loop over processes or even detect them unless you already know the name of what you want to look at.

As for the problem of full-screen applications interfering, there is a test you can do to figure out what is the problem. Just assign any application to a function key, and try to open it when an app is in full-screen. If it works, AppleScript is the problem. If it doesn't work, the design of the system is the problem.

[BryMD]

Hi Daniel!

Thanks for good input.

Most of the scripts never call on Finder directly, but rather on 'Jon's Commands' AppleScript additions. What Jon's Commands does from thereon out is beyond me. Would you guess this problem to be specific to Jon's commands, or would Finder be brought to the foreground regardless of which additions are being used considering I'm manipulating sound and display parameters?

In case of the latter, is there any way for AppleScript to catch the frontmost application in OS 9? If so it would be a partial solution to use conditionals along the lines of:

Set a to frontmost application
If application 'Finder' is frontmost application then
...
Else
...
Activate application a
End if

As for the scripts not executing when applications are running full screen, Apple's own Eject Extras work fine when assigned to an F-key. Apple wouldn't keep the ability to launch applications when other applications are running full screen all to themselves, or would they?

[Daniel]

I think the Finder AppleScript dictionary has things related to setting control panel settings in it, so I believe you would have to bring the Finder to the front to use them (if you were only using AppleScript. Jon's Commands might not be written in AppleScript, so it might not have to have that restriction).

So far, I have not been able to get the current application, and I have found nothing in the documentation that even suggests it can be done. AFAIK, the only way to even interact with applications is with the application keyword.

I know how to hide the Finder after the script runs, but I don't think that is exactly what you want.

[GaryN]

Hi Daniel!

Thanks for good input.

Most of the scripts never call on Finder directly, but rather on 'Jon's Commands' AppleScript additions. What Jon's Commands does from thereon out is beyond me. Would you guess this problem to be specific to Jon's commands, or would Finder be brought to the foreground regardless of which additions are being used considering I'm manipulating sound and display parameters?

In case of the latter, is there any way for AppleScript to catch the frontmost application in OS 9? If so it would be a partial solution to use conditionals along the lines of:

Set a to frontmost application
If application 'Finder' is frontmost application then
...
Else
...
Activate application a
End if

As for the scripts not executing when applications are running full screen, Apple's own Eject Extras work fine when assigned to an F-key. Apple wouldn't keep the ability to launch applications when other applications are running full screen all to themselves, or would they?

Have you ever used Quickeys? It's a scriptable macro maker / F-key maker / all-around utility that's available on MacGarden.
It does many of the things you're trying to use Applescript for and will run "in the background" without calling apps to the front etc.
I suggest it because it will also call Applescripts and can be called by Applescripts, allowing you to integrate the two into something that's greater than the sum of the parts.
Between the two, there's almost nothing you can't do. (Hey, that rhymes!)

[BryMD]

Daniel:
As far as my diagnostic reasoning goes it might be a problem with how Jon's Commands passes on the commands. I might write Jon directly to hear if he still remembers what makes his scripting additions tick

[BryMD]

Hi Gary!

Was waiting for the 'Quickeys-response'

I've seriously considered using Quickeys at several points, but was hoping to perform my magic without too many dependencies - especially Quickeys that the developers are still supporting/quasi-supporting. But if push comes to shove, this is still my escape-route

Is there any other dependencies than Quickeys or perhaps another scripting addition than Jon's you know of that would serve the purpose? *wondering*

Just recently gotten back onto scripting/programming for Mac OS 9, and my thought process is severely tainted from all those years on X.

[GaryN]

Hi Gary!

Was waiting for the 'Quickeys-response'

I've seriously considered using Quickeys at several points, but was hoping to perform my magic without too many dependencies - especially Quickeys that the developers are still supporting/quasi-supporting. But if push comes to shove, this is still my escape-route

Is there any other dependencies than Quickeys or perhaps another scripting addition than Jon's you know of that would serve the purpose? *wondering*

Just recently gotten back onto scripting/programming for Mac OS 9, and my thought process is severely tainted from all those years on X.

That's the best suggestion I have. I get your point about avoiding dependencies, but as a last resort, it's a damn good one.
Once it's installed and running, it becomes as much like a part of the System as you could ever ask for. The integration is excellent.
Mainly though, it will help get past the things Applescript just refuses to do.

[BryMD]

BREAKTHROUGH! AppleScript actually CAN identify the frontmost application:

tell application "Finder"
   set a to (name of processes whose frontmost is true) as text
end tell

Will play around a little with this towards the weekend.

Now how do we effectively force Functional Keys to run when the frontmost application is running full screen?

[Daniel]

BREAKTHROUGH! AppleScript actually CAN identify the frontmost application:

tell application "Finder"
   set a to (name of processes whose frontmost is true) as text
end tell

Will play around a little with this towards the weekend.

Now how do we effectively force Functional Keys to run when the frontmost application is running full screen?

Cool. I tried to do that, but I don't really know AppleScript and got the syntax wrong.

You presumably now have to set the 'background-only' resource fork setting so that you don't always get back the name of the AppleScript applet. Or do you? I don't know how AppleScript works...

[BryMD]

No worries, man! Checked the code, and it's gold. However, severely hampered these days with only Mac OS 9.0 running in SheepShaver, and 9.0 doesn't have options in Keyboard to assign applications to the function keys.

Will try to do a blind recode closer to a weekend, but would be ETERNALLY grateful if someone could beta the result on a 9.2 machine then.

[OS923]

I think that Apple's Eject extras worked like you expected because this is a faceless application. It never uses any of the interface instructions. Your software is a compiled Apple script, a standalone application with the potential of showing a window, for example because an error occurs. That causes Finder to treat it like a normal program, even if it never intentionally opens a window. (If you change the resource into background-only and it opens a window then you will crash.) The Mac OS has an instruction that allows a program, Finder in this case, to launch another program, and when that program never switched to another program and it quits, then it's normal that the control returns to the launching program, Finder, which is then activated.

You can try to make and send your Apple events in a background-only C or C++ program, events that are equivalent to what you do in your Apple scripts.

And instead of using AppleScript you could first try to find out whether this can be done differently, maybe using a low memory variable or a Gestalt or a Sprocket.

If that doesn't work then it's time to write an extension similar to Quickeys.

[BryMD]

Hi OS923! Badass name, by the way

This is PURE GOLD!! It totally explains both why Finder is activated, and why the AppleScripts won't launch when apps are running full screen (read: classic Finder's lack of true preemptive multitasking).

Kind of sucks, but at least I know that the best case scenario by following the current road is that Functional Keys will briefly activate Finder before returning to the frontmost application. And for full screen apps... well... I'm sh*t out of luck

[BryMD]

Hi guys

Just thought I'd take a minute to update you all on the progress with Functional Keys.

Functional Keys is alive an well, and has already reached version 1.9. Version 2.0 is just around the corner, but depends on me getting back to my Mac museum to be able to add dual iTunes/Audion media controls as well as an InstallerVISE installer.



As for the problems with Finder activation and fullscreen incompatibility, OS923 was onto something seriously ingenious - though, ironically, not in the way he intended (or at least not in the way I understood he intended ).

After a lot of trial and error, the problem of Finder activation was located to be Apple and their haphazard implementation of their F-key launcher in OS 9. Apple's solution was to force every command though the Finder - even if none of the commands called on Finder itself. As such, I found a third party F-key launcher, creatively called 'KeyboardLauncher', that bypassed Apple's own short sightedness.

And during my trials (and unspeakable ammounts of failures) I also stumbled upon 'OtherMenu', which adds menu bar controls for Functional Keys. Think of it much like what Ambrosia's 'ColorSwitch Pro' did for earlier systems, though much more versatile. So now Functional Keys can be reached from either the keyboard or from the menu bar, or both - and you can finally get rid of that horrid appendix known as the Control Strip once and for all

As for fullscreen applications, this is where OS923 hit the nail right on the head. By setting 'Background Only' to 'True' in the resource fork - sound, depth, and resolution can finally be controlled without leaving the game.

However, the latter also breaks functionality with System 7, since 'Background Only' makes sense only when operating in a multithreading environment - something which Apple didn't implement until OS 8. I have created a separate version of Functional Keys with OS 7 compatibility, that will be released as part of Functional Keys 2.0.

I've now beta-ed version 2.0 on both OS 9.0 and OS 7.5 and they both work flawlessly, both from the keyboard and from the menu bar. However, still have 1 question remaining to be answered: Where does the backwards compatibility of the OS 9 version end? This is needed before I can build a proper installer that installs the right version of Functional Keys according to both OS version and processor architecture.

And in that respect: Is there anyone here at OS9Lives that could quickly beta-test Functional Keys 1.9 either on OS 8.0 or OS 8.1? Whether on an emulator or on real hardware shouldn't matter. I would be TRULY grateful if anyone here at OS9Lives would help me with this one!

Anyways, Functional Keys 1.9 is available for download here: http://macintoshgarden.org/apps/functional-keys/.

Enjoy