Build applescript based on global fields?

[Rob Reynolds]

I am trying to build an applescript within FM that will mount a network share based on the contents of global fields that contain the ip of the remote machine, the share point, the user name, and the password. The applescript script itself is contained in another global field that is calculated at run time to combine the other fields with static text to get it into the proper applescript form. I then tell the FM applescript step to use that global field for the applescript. It ends up looking something like this:

property AFPdisk : "afp://192.168.123.110/thesharepoint"

property AFPuser : "theusername"

property AFPpswd : "thepassword"

try

mount volume AFPdisk as user name AFPuser with password AFPpswd

end try

When I run the applescript, I get this error message: "An unknown token can't go after this some object (Error -2740)" I tried doing it as above (with properties) and also by simply integrating my FM globals directly into the "mount" statement. It did not work either way.

If I copy the global field that contains the built script into the "script text" area of a FM applescript step and run that FM script, the applescript works (the share point mounts).

Anyone know what the problem might be? I'll be the first to admit I'm an applescript newbie -- if anyone has suggestions on how I might better achieve these results, please let me know.

Some other questions that came up with this:

-- I have to include the applescript globals/variables in quotes. Is there some way to include quotes in an FM script and have them not interpreted as marking off static text? As it now stands, I used a global that contains just a double quote, and I put that global before and after variables that need to be enclosed in quotes. FYI, I'm doing it this way because I'd rather be able to just put the required variables in the global fields, without having to remember to enclose them in quotes.

Thanks for any help!

Rob

[Rob Reynolds]

After scratching my head for a day and playing around some more with this, I *was* able to get it to work. It prolly would have helped if I had included an error capture routine in the applescript -- I'll have to study up on that one... It turns out I was specifying an incorrect IP number, to a machine that would not accept a connection. When I changed the IP to the correct machine, it worked like a charm!

[spragueg]

You can also use fetch style addresses like this. They tend to be less prone to being broken by OS updates.

afp://user:pass@address/volume