A subtle conceptual difference, but then I still don't get it completely. Thanks.

Looks good yellow.

Looks fine, yellow.

Some changes you could make. If you check to see if the network share doesn't exist - and do that first, you can eliminate the code duplication. Also assigning a pointer to the new Finder window makes it clear which window will change. Users may already have a 'Finder window 1' open.

In general in programming it is a bad idea to loop while doing nothing unless you are deliberately trying to consume CPU power.
Thus I would prefer to see some sort of 'delay' inside the repeat loop that waits for the disk to mount. Something like this:
And it is also a bad idea in general to have a loop which may not terminate. The above loop will go on forever if the disk doesn't mount for some reason.
It would be better to have it exit the loop after a while - e.g. after a fixed (large) number of iterations. Something like:

Thanks for the continued input, I really appreciate it!

I took (parts) of the your suggestions and put them in the code. I think the removal of the code redundancy will wait until v2 (Cocoa version?), as the script/app is very small, it doesn't really bother me at the moment.. even though it's probably "good form" programatically. I just need to get something workable 'out-the-door' (so to speak) and then I can concentrate on cleaning it up and stuff like asking for/using values like 'username', so I don't have to recreate the wheel for each user.

You're quite right about the 'Finder window 1' (I actually took that from recording some actions in the Finder to see what the associated AppleScript would be), so I've implemented your use of the mountFoo variables.

And the addition of the delay and associated sane exiting on failure is also a great help and has made it's way into the script.

Thanks again!

EDIT: I'm experimenting with:

set _username_ to "yellow" as string

With hopes that this will populate _username_ throught the script. I'm just not sure how it will be handled in the "mount volume" line.

RE-EDIT: I used guardian's "&_username_&" suggestion and it worked!

My next suggestion was going to be removing the repeat loop altogether. :)
The previous 'on error' statement should catch any mounting issues. Yellow, you can get error codes sent to the 'on error' handler so that you can handle different errors in the same handler. Bet it's in your book.

I'd replace the loop with a single delay statement. The second error handler would deal with any problems associated with being unable to get the correct full path to the SMB share.

Hehe, yep, 6 chapters to go before "Error handling"

I find the evolution of the script quite interesting and wonder what the final will look like once I reach the end of the book and you all get tired of helping me. :)

try using

EDIT>>

this gets the OSX user name. Not sure if you are using the same user name on the smb

That's freaking sweet! Thanks!

In that statement, 1 is an index value, which is "the number of the window in the front-to-back layer ordering". The front window will always have an index of 1. (An alternative way to address the front window is to say "front Finder window".) However, it would be better to address a window by name or id (just in case).


The delay command is a CPU hog (check Activity Monitor sometime). If you are going to delay for more than a couple seconds, I would try to use this instead:
Definitely! Good solution.


For reference, you can also get "full name" and "home directory".

I had heard this in the past and so before recommending the use of 'delay', I checked the CPU usage of the simple script below and found it to be minimal on my 1.2GHz iBook with 10.3.8.
Does this script take much CPU on your system?

Yes it does.. (I have a dual processor 1.33GHz G4), I'd say the average CPU% usage was at ~100%.

On my Mac mini, total CPU usage was ~100%, with Script Editor using ~70%.

I think that's the problem.
Script Editor isn't a good test environment for determining deployment considerations.
When I run the above script from Script Editor on my iBook, it also shows CPU usage approaching 100%. But if I save it as a compiled Application, and run that, the CPU usage averages less than 1 %.

Same here, saved as an app, it maxed out at 1%. Larger RAM usage then with Script Ed, though.. about 50% larger.

I don't save everything as a compiled application though.

Most of my AppleScripts are inserted as scripts into QuicKeys X3 so I can run them with a hotkey or easily call them from another QK sequence. Run in that way, a delay is not the CPU eater I thought it was; QK uses less than 4% of CPU time, declining to 1 at the point that the delay times out. Perhaps an AS delay is now using the sleep shell function.