Re: Smile - new window with properties [and a tip]
Re: Smile - new window with properties [and a tip]
- Subject: Re: Smile - new window with properties [and a tip]
- From: "Vince Jelenic" <email@hidden>
- Date: Mon, 20 Nov 2000 15:54:32 -0500
>
> So then, we could create a new folder inside System folder, let's call
>
it
>
> "Application Aliases", and just put aliases to all our applications
>
there. I
>
> like that better than cluttering up the Scripting Additions folder with
>
> aliases.
>
>
Unfortunately, that won't work. AppleScript 1.4 doesn't search *all*
>
folders
>
in the System Folder, just the Control Panels, Extensions, and Scripting
>
Additions folders, plus the System Folder itself. I'm afraid the release
>
notes
>
lie slightly...
>
so must go into control panels.
I kinda don't like the idea of aliases to programs cluttering ANY folder.
Kinda leery of the alias resolution problems we've been encountering way
back since system 8.x
Let me see if I get it so far. just digging.
If app "XY" is already running, then applescript can tell application "XY"
to do whatever.
This works flawlessly, right ?
if app XY is not yet running, then applescript does not know which app you
refer to.
If you run the script, it will ask for location,
If you compile script after finding location, it will then KNOW the
location for next time it's run.
move script to another machine, and you have to locate the app again.
This is the dreaded scenario?
I've held off implementing applescript for quite some time due to it's
reduced portability between machines led by this glitch.
especially run-only apps which must automate any portions of workflow.
I assume it has not yet been solved.
In that light, recently, I was looking at keeping filemaker dbase open
with script which are runnable by multiple users on our network.
the only solution I've come up with is to keep data in an associated
database which ensures that the app is found.
I'm doing it this way.
1. scripts dbase and apps dbase are open.
2. script calls application processes, if the app is not yet running then
3. it calls routine which finds app name in the apps database. here, each
machine has a marker for app XY, the user name, and the location of the
app on the disk. obviously with all the error checking for duplicates,
missing apps, etc.
4. if the app is not found in the apps dbase, it creates new record for
this user, asking them to locate the app.
5. if app is found, but the file location has changed, or is missing, or
new version number has been installed, it deletes current record replacing
with new one, asks user to locate.
6. if, instead if found app info, the file exists in proper location, it
tells finder to open this file.
In this case, the app is activated by force before the rest of the script
is run.
Thus telling app "XY" is preceded by the dbase check for the app info,
activating app if not running, then proceeding with work.
This dbase approach remembers the locations of the files, so with a little
rigidity, it should work for a few months for each app before changes are
required. The only point where error can occur is when user navigates to
the app.
Have not implemented yet, still in work stages, but has anyone used such
an approach?
However, kinda reminds me how powerful frontier was. this process was a
one-liner, basically , in that language .
with objectmodel, qxp
launch()
or simply launch.usingID("XPR3") and quark is launched
Is the differenct because Frontier speaks directly to the sytem while
Applescript must go through finder ?
I have to do allthis stuff above to get applescript to work across macs.
The question is , why isn't the following line possible with applescript,
or why can't it be ?
launch every application whose type is "APPL" and creator is "XPR3" (or
backwards...)
It's a hit/miss for me to knowing when a script will run on any given
machine as I move about the office.
gotta be a better way.
OR, is there a very fast/simple way to isolate an application with these
characteristics, perhaps using an osax ?
(by fast, I mean in the range of 1-2 seconds on a file system with about
20,000++ files)
------ Vince Jelenic says:
"The only way to really ensure server security is to lock it in a sealed
room with the power off."