Category Archives: applescript

The Monty Hall problem

Posted on by
Reply

The Monty Hall problem is based on a TV game show where you, as the contestant, are presented with three doors. Behind one door is an awesome prize. You just have to guess which door has the prize behind it.

After you make your choice (C), the host reveals what is behind one of the other doors (it’s never the awesome prize). Then you are given the option to stay with your original decision, or change to the other remaining door.

The problem is this: Should you change your mind and choose the other door, or should you stay with your original choice?

NOW, there’s a mathematical proof that you should definitely change doors. And I wanted to set up an Applescript to demonstrate that this is so.

You COULD create a script which let’s you emulate the game. The below script let’s you choose a door, and then change your mind (or not) and gives you a readout of your progress (wins vs losses).

And that can be a bit of fun … for about 2 minutes … tops.

set TheDoors to {"Door 1", "Door 2", "Door 3"}
set TheWin to 0
set TheLoss to 0

my mgPlay(TheDoors, TheWin, TheLoss)

on mgPlay(TheDoors, TheWin, TheLoss)
	set WinningDoor to some item in TheDoors
	set ChosenDoor to (choose from list TheDoors with title "Monty Hall" with prompt "Which door do you choose?")
	if result is false then
		error number -128
	end if
	set ClosedDoors to {WinningDoor, (item 1 of ChosenDoor)}
	set OpenDoors to {}
	repeat with ThisDoor in TheDoors
		if ThisDoor is not in ClosedDoors then
			set end of OpenDoors to (ThisDoor as string)
		end if
	end repeat
	set OpenDoor to some item in OpenDoors
	set NewDoors to {}
	repeat with ThisDoor in TheDoors
		if (ThisDoor as string) is not OpenDoor then
			set end of NewDoors to (ThisDoor as string)
		end if
	end repeat
	set TheString to "You chose " & ChosenDoor & return & return & "Now Monty has opened " & OpenDoor & return & return & "You may now choose to change your mind or stay with " & ChosenDoor & return & return
	set FinalDoor to (choose from list NewDoors with title "Monty Hall – Second Chance" with prompt TheString)
	set FinalDoor to item 1 of FinalDoor
	if FinalDoor = (ChosenDoor as string) then
		set TheString to "You chose to stay with " & ChosenDoor & return & return
	else
		set TheString to "You chose to change from " & ChosenDoor & " to " & FinalDoor & return & return
	end if
	if FinalDoor = WinningDoor then
		set TheWin to TheWin + 1
		set TheString to TheString & "Congratulations. " & FinalDoor & " is correct" & return & "You won this round" & return & return & "You have won " & TheWin & " and lost " & TheLoss
	else
		set TheLoss to TheLoss + 1
		set TheString to TheString & "Sorry. " & FinalDoor & " is not correct" & return & "THE WINNING DOOR WAS " & WinningDoor & return & "You didn't win this round" & return & return & "You have won " & TheWin & " and lost " & TheLoss
	end if
	set ThisChoice to display dialog TheString buttons {"STOP PLAYING", "PLAY AGAIN"}
	set ThisButton to button returned of ThisChoice
	if ThisButton is "PLAY AGAIN" then
		my mgPlay(TheDoors, TheWin, TheLoss)
	else
		display dialog "Thanks for playing" buttons {"OK"}
	end if
end mgPlay

But to see a definite pattern in the results, we need to run hundreds of games. And the process above is just too tedious. If we could automate the entire process, we could run 10,000 games in about a second.

First (see below) we set up four counters to keep track of our success rate. The next two lines are two lists to represent the contestant’s possible choices. The next two lines access the first list to randomly select a Winning Door and the contestant’s Chosen Door. This is what some item means. It means choose a random entry from any given list. The last line puts those results into a list of doors which must remain closed for the second part of the game. This list might contain only one door if the Winning Door is the same as the Chosen Door.

set NoChangeWin to 0
set NoChangeLose to 0
set YesChangeWin to 0
set YesChangeLose to 0

set TheDoors to {"Door 1", "Door 2", "Door 3"}
set TheChoices to {"Change Choice", "Don't Change Choice"} 

set WinningDoor to some item in TheDoors
set ChosenDoor to some item in TheDoors

set ClosedDoors to {WinningDoor, ChosenDoor}

The next section chooses a door to open. Remember, this cannot be the Winning Door, nor can it be the contestant’s Chosen Door. So first we put all the possible doors to open into a list (this list could contain either one or two doors), then choose a random door from that list to open.

Then the next section puts the two remaining closed doors into a list for the contestant to choose from again.

set OpenDoors to {}
repeat with ThisDoor in TheDoors
	if ThisDoor is not in ClosedDoors then
		set end of OpenDoors to (ThisDoor as string)
	end if
end repeat
set OpenDoor to some item in OpenDoors

set NewDoors to {}
repeat with ThisDoor in TheDoors
	if (ThisDoor as string) is not OpenDoor then
		set end of NewDoors to (ThisDoor as string)
	end if
end repeat

The next section is just a little more complicated. First we get a random choice from that second list from the start of the script. This represents whether or not the contestant changes their mind about which door they want. Then we use some nested if statements to determine the results.

Firstly, if the choice is to NOT change, then we set the Final Door to be the same as the original Chosen Door. Then we check to see if the Final Door is the same as the Winning Door randomly selected at the start of the script. If it is, we add 1 to the NoChangeWin counter. If it’s not the same, we add 1 to the NoChangeLose counter.

The second part below – the else statement – is for when the contestant DOES choose to change doors. We use a quick repeat loop to select the other door from the list of two closed doors to be our Final Door. Then run the same analysis as above. If the Final Door is the same as the Winning Door, we add 1 to the YesChangeWin counter. If it’s not the same, we add 1 to the YesChangeLose counter.

set TheChoice to some item in TheChoices
if TheChoice is "Don't Change Door Choice" then
	set FinalDoor to ChosenDoor
	if WinningDoor = FinalDoor then
		set NoChangeWin to NoChangeWin + 1
	else
		set NoChangeLose to NoChangeLose + 1
	end if
else
	repeat with ThisDoor in NewDoors
		if (ThisDoor as string) is not ChosenDoor then
			set FinalDoor to (ThisDoor as string)
		end if
	end repeat
	if WinningDoor = FinalDoor then
		set YesChangeWin to YesChangeWin + 1
	else
		set YesChangeLose to YesChangeLose + 1
	end if
end if

The final part is our reporting. This simply creates four lines of text with the various outcomes (win after not changing, lose after not changing, win after changing, lose after changing)

return "Contestant wins after NOT changing : " & NoChangeWin & return & "Contestant loses after NOT changing : " & NoChangeLose & return & return & "Contestant wins after changing  : " & YesChangeWin & return & "Contestant loses after changing  : " & YesChangeLose

Now all we need to do is put the whole lot together and include a repeat loop to generate as many games as we please. I found that 1,000,000 games takes about 27 seconds to run. But that’s a bit ridiculous because you don’t really need more than 10,000 games to show the pattern.

Here is the complete script with commenting included. Plus, below that, a sample of the output for 10,000 games.

--these are counters to track wins/losses
set NoChangeWin to 0
set NoChangeLose to 0
set YesChangeWin to 0
set YesChangeLose to 0

-- this is the list of possible doors to choose at the start
set TheDoors to {"Door 1", "Door 2", "Door 3"}

-- this is the list of possible contestant choices at the end
set TheChoices to {"Change Choice", "Don't Change Choice"}

repeat 10000 times
	-- randomly select a winning door
	set WinningDoor to some item in TheDoors
	
	-- randomly select the contestant's chosen door
	set ChosenDoor to some item in TheDoors
	
	-- put these into a list (they might be the same door)
	set ClosedDoors to {WinningDoor, ChosenDoor}
	
	-- randomly select a door to open
	-- it can't be the winning door, nor the contestant's chosen door
	set OpenDoors to {}
	repeat with ThisDoor in TheDoors
		if ThisDoor is not in ClosedDoors then
			set end of OpenDoors to (ThisDoor as string)
		end if
	end repeat
	set OpenDoor to some item in OpenDoors
	
	-- set the NEW list of possible doors to choose 
	-- this is a list of two doors (now that one door is open)
	set NewDoors to {}
	repeat with ThisDoor in TheDoors
		if (ThisDoor as string) is not OpenDoor then
			set end of NewDoors to (ThisDoor as string)
		end if
	end repeat
	
	-- randomly select if contestant will change their choice or not change
	-- and count how often contestant wins vs loses
	set TheChoice to some item in TheChoices
	if TheChoice is "Don't Change Choice" then
		set FinalDoor to ChosenDoor
		if WinningDoor = FinalDoor then
			set NoChangeWin to NoChangeWin + 1
		else
			set NoChangeLose to NoChangeLose + 1
		end if
	else
		repeat with ThisDoor in NewDoors
			if (ThisDoor as string) is not ChosenDoor then
				set FinalDoor to (ThisDoor as string)
			end if
		end repeat
		if WinningDoor = FinalDoor then
			set YesChangeWin to YesChangeWin + 1
		else
			set YesChangeLose to YesChangeLose + 1
		end if
	end if
end repeat

return "Contestant wins after NOT changing : " & NoChangeWin & return & "Contestant loses after NOT changing : " & NoChangeLose & return & return & "Contestant wins after changing  : " & YesChangeWin & return & "Contestant loses after changing  : " & YesChangeLose

Contestant wins after NOT changing : 1663
Contestant loses after NOT changing : 3353

Contestant wins after changing  : 3330
Contestant loses after changing  : 1654

If you run this script for 10,000 games over and over again you’ll see very similar results. That is, you will win the Monty Hall game approximately twice as often if you change your choice when presented with the two doors.

Now this may seem counter-intuitive (it did for me) because, surely, if you’re presented with only two doors, you’ve got a fifty-fifty chance of picking the right door. I mean, there’s just two doors, so it shouldn’t really matter which one you choose … right?

Well, yes, that would be true if you had not already been presented with the three doors.

Here’s how it works …

You’re presented with three doors and you choose one. Let’s just say you choose the first door.

If you choose the first door, all the possible scenarios for the winning door look like this (below). And the same is the case if you choose the middle door or the last door – no matter which door you choose, there are three possibilities for the winning door.

Then Monty Hall opens one of the doors. In the first scenario, there’s a choice of two doors to open. In the other two, there’s only one door that could be opened.

But the kicker is this … you don’t know which of the three scenarios is in play. But looking at this diagram it should be obvious that out of the three possible scenarios, only one sees you winning if you keep the same door. Whereas there are two possible scenarios where you will win if you change.

Of course, this does not guarantee you a win if you change doors. But, on average, you’ll win twice as often if you change.

Keep grunting

macgrunt icon

InDesign scripting : lesson 36

Posted on by
1

throughout this site (and others) you’ll find lots of applescripts which are direct responses to real-world workflows. but, chances are, you’ll need to do some cut-pasting, and additional code writing to create a script which does exactly what you want in your workflow.

this can be a bit intimidating and not a little frustrating as you try to get the bloody thing to work.

so here’s a post (and there may be more to follow) which gets back to basics and addresses a common beginner question :

When I’m cutting and pasting sections of a script, how many ‘end tells’ do I need to include?

new scripters will often be confronted with errors like these when trying to compile or run a script in development :
end error 01
end error 02

one of the main problems with this kind of error, as compared with many other types of errors, is that Applescript Editor may not highlight the exact line where the problem needs to be fixed.

the important thing to remember is that the number of ‘end tells’ will be exactly the same as the number of ‘tells’.

when writing code from scratch, it’s best practice to write the ‘tell’ and ‘end tell’ first — then go back and fill in the rest of the code :

tell application id "com.adobe.InDesign"
-- rest of code here
end tell

you can have tells within tells (or nested tells) — these get closed off in the reverse order that they were opened — but notice, still, the number of ‘end tells’ is the same as the number of ‘tells’ :

tell application id "com.adobe.InDesign"
  -- code here addresses the application
  tell active document
    -- code here addresses the active document
    tell layout window 1
      -- code here addresses the layout window
    end tell
    -- code here addresses the active document
  end tell
  -- code here addresses the application
end tell



other commands
this is also the case with other commands that need an ‘end’ statement. for example, if you have an ‘if’ command within a ‘tell’ command, the ‘if’ needs to end before the ‘tell’ ends :

tell application id "com.adobe.InDesign"
  if x = y then
    -- some more code
  end if
end tell

when writing code you can also close off with just ‘end’ and the editor will work out which end goes with which command when the script is compiled. so you can write it out like this :

tell application id "com.adobe.InDesign"
tell active document
if x = y then
repeat 5 times
-- some more code
end
end
end
end

… and, when compiled, it will become this :

tell application id "com.adobe.InDesign"
  tell active document
    if x = y then
      repeat 5 times
        -- some more code
      end repeat
    end if
  end tell
end tell

but you can see that even here — all the commands get closed down in the reverse order that they were opened. the ‘repeat’ is closed first, then the ‘if’, then the second ‘tell’ and lastly the first ‘tell’.



… and another thing
whenever possible, it’s best to avoid one application ‘telling’ another application :

tell application id "com.adobe.InDesign"
  set mgFolder to file path of active document
  tell application "Finder"
    set mgOLDFolder to (mgJobFolder & "OLD:" as string) as alias
  end tell
end tell

… is better writen as :

tell application id "com.adobe.InDesign"
  set mgFolder to file path of active document
end tell
tell application "Finder"
  set mgOLDFolder to (mgJobFolder & "OLD:" as string) as alias
end tell

… where we close the InDesign tell before opening the Finder tell



are there other scripting issues that keep cropping up for you?

macgrunt icon

InDesign scripting : lesson 35

Posted on by
Reply

miracles happen

macgrunt has now received at least two undeniable confirmations of the medicinal properties of applescript : the first was from a generous commenter on one of the earlier lessons which you can read here ; and the second was from a user who asked for assistance with a different exporting problem (which is what this post will be about, eventually). to quote :

The joy also helped ease my sciatic nerve pain I have been suffering for more than a month now.

now, the cynical among you may think that these people are exaggerating or just being flippant — but do you really have a good and verifiable reason to doubt the written testimony of fellow mac users? not likely.

here’s the brief for the sciatica-easing workflow : export the active document to 300ppi CMYK jpegs and 150ppi RGB pngs.

the first part of the script is pretty similar to all the other exporting scripts on this site — get the filename and path of the active document, shorten the filename so that the names of the exported images won’t be too long, create some folders to hold the exported images :

-- developed by macgrunt for use with InDesign
-- last updated April 2014
-- macgrunt.com

-- export jpgs and pngs from active InDesign document

tell application id "com.adobe.InDesign"
  set mgFolder to file path of active document
  set mgDocName to name of active document
end tell

----------------------------------
-- this bit shortens filename to first space
set text item delimiters of AppleScript to {" "}
set mgDocName to text item 1 of mgDocName
set text item delimiters of AppleScript to ""
----------------------------------

----------------------------------
-- this bit creates subfolders in the same location as the InDesign file
tell application "Finder"
  if (exists folder "JPGs" of folder mgFolder) is false then
    set mgJPGfolder to make new folder at mgFolder with properties {name:"JPGs"}
  else
    set mgJPGfolder to (mgFolder & "JPGs") as string
  end if
  set mgJPGfolder to mgJPGfolder as alias
  if (exists folder "PNGs" of folder mgFolder) is false then
    set mgPNGFolder to make new folder at mgFolder with properties {name:"PNGs"}
  else
    set mgPNGFolder to (mgFolder & "PNGs") as string
  end if
  set mgPNGFolder to mgPNGFolder as alias
end tell
----------------------------------

hopefully it’s clear that mgFolder is where the InDesign file is saved, so the new JPGs and PNGs folders are created in that same folder. these new folders are created using an if/then/else routine — if you just tried to create the new folder when there was already one there, the script would throw an error — and that’s tedious.

the second half of the script sets the export parameters and does the actual exporting — pretty simple :

tell application id "com.adobe.InDesign"
  ----------------------------------
  -- here is where we set the export parameters
  set Exporting Spread of JPEG export preferences to false
  set JPEG export range of JPEG export preferences to export range
  set JPEG Quality of JPEG export preferences to maximum
  set jpeg color space of JPEG export preferences to CMYK
  set export resolution of JPEG export preferences to 300
  
  set Exporting Spread of PNG export preferences to false
  set PNG export range of PNG export preferences to export range
  set PNG Quality of PNG export preferences to maximum
  set PNG color space of PNG export preferences to RGB
  set export resolution of PNG export preferences to 150
  ----------------------------------
  
  repeat with mgCount from 1 to (count pages of active document)
    set mgCount to mgCount as string
    set Page String of JPEG export preferences to mgCount
    set Page String of PNG export preferences to mgCount
    set mgJpgFilePath to (mgJPGfolder & mgDocName & "_" & mgCount & ".jpg") as string
    set mgPNGFilePath to (mgPNGFolder & mgDocName & "_" & mgCount & ".png") as string
    tell active document
      export format JPG to mgJpgFilePath without showing options
      export format PNG format to mgPNGFilePath without showing options
    end tell
  end repeat
  
  display dialog "ALL DONE!" buttons {"Okey-dokey"} default button 1
end tell

this block of code highlights one of the frustrating things about trying to write applescript — the inconsistency of syntax. notice how ‘jpeg color space’ is not capitalised like all the other export preference properties? that’s not really a big deal because the script editor will correct that automatically if you accidentally type it in caps.

but notice the two export commands : ‘export format JPG’ vs ‘export format PNG format’ — why do they have different structures? who knows — adobe are just weird. it’s even weirder when you include the two PDF export commands : ‘export format PDF type’ vs ‘export format interactive PDF’. best not to think about it.

that repeat loop at the end is purely to get consistency of filenaming. if we just export a document “mgThis_file.indd” to jpegs, the filenames would be “mgThis_file.jpg”, “mgThis_file2.jpg”, “mgThis_file3.jpg”, etc. again with the inconsistency … why doesn’t InDesign add ‘1’ to that first jpg? — adobe really do have some serious explaining to do.

anyway, as we were adding a repeat loop to include ‘1’ on the first image, we took the opportunity to add an undescore as well. so these files would now come out as “mgThis_file_1.jpg”, “mgThis_file_2.jpg”, “mgThis_file_3.jpg”, etc.

obviously, this is a very basic script which exports a single document at a time, using one set of export preferences. but like all the PDF export scripts on this site, it doesn’t take much to adapt it to export all open documents, or give the user the chance to choose export preferences.

keep grunting.

macgrunt icon

renaming finder items IV — part 3

Posted on by
1

the last two posts looked at using applescript to develop an app to make batch renaming finder items even easier than automator, or bridge, or whatever. first, we created the basic functionality, then we improved the script to make it more user friendly. this post will be the final instalment — the final revision to optimise usability.

to understand this post you’ll first need to review renaming finder items IV and renaming finder items IV — part 2.

the app has been created as a droplet — drop files on the app’s icon and they are processed by the script. pretty simple. but the app would be better still if it could be activated in a number of ways. so, we’re going to alter it so that, as well as accepting dropped files, it can accept a dropped folder of files, or just run when it is double-clicked.

it would also be better if it ran faster.

making it faster is easy. in its current form the script will rename 1000 files in a bit over a minute — not bad. but if you take every instance of this line :

tell application "Finder"

and replace it with :

tell application "System Events"

you’ll find that renaming 1000 files will take about a second. that’s even more not bad.

“System Events is an agent (or faceless background application) that supplies the terminology for using a number of features in AppleScript scripts. … Provides terminology to access disks, files, and folders without targeting the Finder. This can be more efficient than using the Finder …”
Mac Developer Library

ok, so much for speed, now for the varied functionality. the original script started with an on open command and assumed that the user would be dropping a bunch of files on the droplet.

here’s how to change that on open command so that it could accept either a bunch of files or a folder :

on open (mgDropped)
  tell application "System Events"
    if (count of mgDropped) = 1 then
      if (mgDropped as string) ends with ":" then
        set mgFiles to files of item 1 of mgDropped
      else
        display dialog "You're really using a script to rename one file?" & return & return & "OK ... whatever."
        set mgFiles to mgDropped
      end if
    else
      set mgFiles to mgDropped
    end if
  end tell
  my mgProcess(mgFiles)
end open

the files to be renamed are now defined by the variable mgFiles before being passed to the subhandler mgProcess. the reason we are now using a subhandler for the renaming is that the on open command is not the only script initiator — we’ll also be including an on run command.

the on run command is what allows the app to run by just double-clicking it. when the app is double-clicked it will ask the user to choose a folder of files to rename — again passing those files to the mgProcess subhandler. so the full start of the script now looks like this :

-- thanks to Yvan Koenig for the on run/on open clue :
-- http://macscripter.net/viewtopic.php?id=41214
on run
  set mgFolder to choose folder
  tell application "System Events"
    set mgFiles to files of mgFolder
  end tell
  my mgProcess(mgFiles)
end run

on open (mgDropped)
  tell application "System Events"
    if (count of mgDropped) = 1 then
      if (mgDropped as string) ends with ":" then
        set mgFiles to files of item 1 of mgDropped
      else
        display dialog "You're really using a script to rename one file?" & return & return & "OK ... whatever."
        set mgFiles to mgDropped
      end if
    else
      set mgFiles to mgDropped
    end if
  end tell
  my mgProcess(mgFiles)
end open
---------------------------------------------

so, to reiterate, having both the on run and on open commands allows this script to behave both as a standard app and as a droplet.

there are a bunch of other minor revisions that need to be made to the original script to accommodate this new functionality — not least the encapsulating of the basic script within a subhandler. the new completed script would look like this :
screen grab of finished EasyRenaming script

but you can get the complete EasyRenaming app here.

have fun improving this script for even greater functionality.


• related post : renaming finder items : renaming using automator or applescript.
• related post : renaming finder items II : renaming by list.
• related post : renaming finder items III : renaming by creation date.

macgrunt icon

renaming finder items IV — part 2

Posted on by
1

today we’re going to look at revising the script from the last post to make it more user friendly and robust. here was what we finished with last time :
screen grab of finished script

you may need to review how that script functions before proceeding : renaming finder items IV

refining a script for optimal usability is largely a matter of asking a bunch of “what if …?” questions. what if the user does this? what if the user does that? what if the user is a thicky? etc.

we’re going to do some simple refinements :

  • what if the user enters nothing in the first dialog? — we’ll give them the option to append something to the start of the filename.
  • what if the user enters nothing in the second dialog? — we’ll give them the option to simply delete the ‘change from’ text from the filename.
  • what if the user doesn’t fully understand what the script is going to do? — we’ll give them a confirmation message before proceeding.
  • how will we know how successful the script was? — we’ll include some extra reporting at the end of the process.

first we’ll add three variables right after the first line of the script :

set mgAppend to "NUP"
set mgChanged to {}
set mgUnChanged to {}

the first is a simple switch we’ll use for an if/then statement when it comes time to actually change the filenames. the other two are empty lists that will get populated as the script processes the files. these will be the basis for the end reporting.

the next part goes straight after presenting the change from dialog. it creates another window to check what to do if the user enters nothing in the change from dialog. this is where the mgAppend variable gets switched if required :

set mgChangeFrom to text returned of mgChangeFromDialog
if mgChangeFrom is "" then
  set mgJustChecking to display dialog "So, do you want to append the new text to the front of the filename?" buttons {"No — Cancel", "Yes — Append"} default button 2
  if button returned of mgJustChecking is "No — Cancel" then
    error number -128
  else
    set mgAppend to "YEP"
  end if
end if

screen grab of append check dialog window

does that all make sense so far?

now after collecting the change from and change to data from the user and running the considering case check, we’ll have three possible scenarios (apart from the script having been cancelled) :

  1. we have nothing for change from and a text string for change to (append)
  2. we have a text string for both change from and change to (replace)
  3. we have a text string for change from but nothing for change to (delete)

we can use those possible scenarios to build one of three possible confirmation dialogs like this :

if mgChangeTO is not "" then
  if mgAppend is "YEP" then
    set mgConfirmationText to "JUST CONFIRMING." & return & return & "Filenames will be changed so that :" & return & "      '" & mgChangeTO & "'." & return & "is appended to the front of each filename." & return & return & "IS THAT CORRECT?"
  else
    set mgConfirmationText to "JUST CONFIRMING." & return & return & "Filenames will be changed so that :" & return & "      '" & mgChangeFrom & "'" & return & "becomes" & return & "      '" & mgChangeTO & "'." & return & return & "IS THAT CORRECT?"
  end if
else
  set mgConfirmationText to "JUST CONFIRMING." & return & return & "Filenames will be changed so that :" & return & "      '" & mgChangeFrom & "'" & return & "is deleted." & return & return & "IS THAT CORRECT?" & return & return & return & "{WARNING : this change cannot be undone}"
end if

set mgConfirmation to display alert mgConfirmationText buttons {"HELL NO! STOP", "YES! Go do that thing"} default button "HELL NO! STOP" as critical
if button returned of mgConfirmation is "HELL NO! STOP" then
  error number -128
end if

screen grab of three confirmation dialog windows

the portion of the script that does the actual name changing is a bit more complicated now. it needs to allow for appending (as required) and for populating those two lists we need for reporting purposes :

tell application "Finder"
  repeat with mgitem in mgSelection
    set mgOriginalName to name of mgitem
    if mgAppend is "YEP" then
      set mgNewName to (mgChangeTO & mgOriginalName) as string
      set name of mgitem to mgNewName
      set end of mgChanged to mgOriginalName
    else
      set text item delimiters of AppleScript to mgChangeFrom
      set mgNameItems to text items of mgOriginalName
      set text item delimiters of AppleScript to ""
      set mgItemCount to count mgNameItems
      if mgItemCount is not 1 then
        set text item delimiters of AppleScript to mgChangeTO
        set mgNewName to mgNameItems as string
        set text item delimiters of AppleScript to "."
        set mgNameCheck to text item 1 of mgNewName
        set text item delimiters of AppleScript to ""
        if mgNameCheck is "" then
          display dialog "Sorry, You cannot have a file with no name at all" buttons "dammit" default button 1
          error number -128
        end if
        set name of mgitem to mgNewName
        set end of mgChanged to mgOriginalName
      else
        set end of mgUnChanged to mgOriginalName
      end if
    end if
  end repeat
end tell

and, finally, we have the reporting process. the original script simply popped up a window saying “All Done”. this version will give the user some helpful feedback :

set mgCountSelection to count mgSelection
set mgCountChanged to count mgChanged
set mgCountUnChanged to count mgUnChanged

if mgUnChanged is not {} then
  if mgCountUnChanged is less than 12 then
    set mgUnChangedList to "They are: " & return & "    "
    repeat with mgUnChangedItem in items of mgUnChanged
      set mgUnChangedList to mgUnChangedList & mgUnChangedItem & return & "    "
    end repeat
  else
    set mgUnChangedList to "Here are some of them: " & return & "    "
    repeat with x from 1 to 10
      set mgUnChangedItem to item x of mgUnChanged
      set mgUnChangedList to mgUnChangedList & mgUnChangedItem & return & "    "
    end repeat
  end if
end if

if mgCountSelection = mgCountChanged then
  set mgMessage to "All " & mgCountSelection & " files were successfully renamed."
else if mgCountSelection = mgCountUnChanged then
  set mgMessage to "Sorry, none of the " & mgCountSelection & " files were successfully renamed." & return & return & "You probably stuffed something up."
else
  set mgMessage to (mgCountChanged & " filenames were successfully renamed." & return & return & (count mgUnChanged) & " filenames were NOT changed because " & return & "they do not contain '" & mgChangeFrom & "'." & return & return & mgUnChangedList) as string
end if

display dialog mgMessage

the dialog will list the names of the unchanged files. if there are too many it will just list the first 10 :
screen grab of the final reporting dialog window

the finished script would look something like this.
screen grab of the finished script

there’s a bunch of different ways to improve this script. the next post will look at changing it so that it can be activated in a number of ways (rather than only by dropping files) and how to make the finished app run MUCH faster.

til then, keep grunting.


• related post : renaming finder items : renaming using automator or applescript.
• related post : renaming finder items II : renaming by list.
• related post : renaming finder items III : renaming by creation date.

macgrunt icon