I asked this in Applescript forum but thought someone might know of another way to accomplish the same end result.

I don't think you are going to have much luck with intercepting the save dialogs used in other applications, but you could possibly copy to the clipboard and/or paste into the current save dialog using the result of the naming utility. AppleScript can do this, but it would be from an Xcode/Cocoa-Applescript type of project, otherwise you are looking at whole bunch of dialogs popping up.

I've looked into developing a custom naming application like this before, but the actual (re)naming part is easy - the hard part is setting up a decent user interface.

I agree with r_m: I don't think you're going to catch the save dialog, not with applescript. You might try some after-the-fact scripting, where the user saves the file with a random name and a folder action or launchd agent renames the file. I don't know how that would fit in your workflow, though.

Actually, after revisiting some of my earlier prototypes, a text service might be the way to go. When a save panel opens, the default name is highlighted, so just right-clicking on it will bring up the services menu. There still isn't a way to force the use of the service, but it would only be a click away.

A regular application can be developed that provides the service, or maybe an Automator action can be created. Going the Automator action route mignt be a little bit faster to develop, but setting up a way to enter and edit the menus will take a little thought.

Wow, never realized you could do this. It's pretty cool! Opens up all sorts of intersting ideas. 🙂

That service shows up in all input windows even the Finder search input field!

Well, I guess that is what they made them for, but I never thought about using them in dialogs, either. I suppose now it's time to dust off that old AS Studio project...

It's crude but as a proof of concept for the OP this automator workflow saved as a text service does pretty much what he wants:

There are a few drawbacks that I see, the two main ones being

1. As it is a service there is no forcing the user to use it when they save the project.

2. In order for the service to show up there needs to be selected text in the text box but this requirement can worked into the workflow

To overcome 2 I see the user inputting the version number in the text box, selecting it and then running the service. The version number can be verified in the script and the user can be prompted to enter it again if it is wrong.

Of course 1 will always be a problem in a situation like this but unless you're coding the app from scratch there is no way to force the user to do this.

But this would still be a big improvement over not having anything to help the user come up with the correct name.

So all that really needs to be done is the coding up of the dialogs to have the user select the those bits.

It is pretty easy to whip up a GUI in an Automator action to keep away from the typical death by dialog, the tricky part is a providing a decent way to edit the menu lists. My previous project used tokens to represent the various menu and date objects, with the format determined by dragging tokens and entering text in the setup text field - a decent way to edit the menu lists was a problem with that as well.

I'll look into an Automator action with the various menu items, maybe it can be modular enough to rearrange the UI items for other formats - any ideas on some kind of management system for the menu items? Maybe property lists or text files could be used, but I found that managing the menu items was way more complicated than anything else.

Remember what I posted was just a proof of concept, there is still more work that will need to be done to this.

I think as a first round and to test out the concept you could get by with a series of choose from dialog windows that the script would put up for the user to select the different bits.

As I wrote the major drawback here is that there is no way to force the user to use this, but given the requirements of your naming scheme I think any user will be happy to use something that will make entering the name easier.

As for replying it really doesn't matter as far as seeing the posts, everyone sees everything posted here.

If you are answering or commenting on something specific in a post it is a good idea to respond to that post so your post makes senses in context. If we don;t know who you are responding to it can sometimes make understanding a post confusing.

regards

As I wrote the major drawback here is that there is no way to force the user to use this, but given the requirements of your naming scheme I think any user will be happy to use something that will make entering the name easier.

This would close the window a bit.

You could put a folder action on the folder to verify the name. If it looks "bad" you could put out a warning.

Robert

Well, the good news is that I reworked my old code over the weekend (using a specific naming sequence made it a whole lot easier) and now have a functioning renamer with most of the bells and whistles intact. The application puts an accessory view in a standard open panel, but the service would look something like:

The bad news is that I'm about to lose what little hair I have left trying to get it to work as a service, and an Automator action doesn't look like it will be any better. The next step is to see if I can use the service application in an Automator service (or other service wrapper) and use it from there.

If anyone else has had success with an ASObjC service, feel free to chime in - I would appreciate some clues.

Xcode is needed for what I posted - I just tweaked a project I started a few years ago, so the basics were already built (there isn't really that much code). The menus are populated with the contents of a .plist file (which can be edited with a text editor), so once the clients, projects, etc, are set up it is just a matter of clicking on the desired menu item - I figured that was the approach you were going for to prevent errors such as typos.

ComboBoxes are used for the menus, which have a text field in addition to the menu, so if the desired menu item isn't there it can be typed in. Addiitons made that way will be added to the list for the next time via the application preferences. The final file name is built as the items are selected, and the rename will not continue until all items are selected (I threw an optional text field in there that doesn't need to be filled in).

The renamer is a working application right now, I'm just having a problem getting it to work as a service. The application puts up a file selection panel where you can select a single file to be renamed (the original application was for renaming scanned documents), so if you would like to take a look at that send me an email (my address is in my profile).

This AppleScript will put up choose from list dialogs to get the user input. It isn;t as clean as what red_menace was working on but this will work as a service.

Right now the user input part is missing and there are no real error checks but it will give you an idea of what can be done

property clientCodeList : {"A1", "A2", "A3"}

property projectCodeList : {"BON", "BOB", "CAT", "DOG"}

property subProjectCodeList : {"showA", "showB", "showC"}

property partCodeList : {"Finale", "Start", "WhatsUp"}

property appUsedCodeList : {"LP", "CD", "QQ", "PP"}

set finalStr to datePart() & "_" & clientCode() & "_" & projectCode() & "_" & subProjectCode() & "_" & partCode() & "_" & appUsedCode() & "_V" & "userInput" & "_AES" & "userInput"

display dialog finalStr

on datePart()

set now to current date

if (day of now < 10) then

set dayStr to "0" & day of now

else

set dayStr to (day of now) as text

end if

if (month of now as integer < 10) then

set monthStr to "0" & (month of now as integer)

else

set monthStr to (month of now as integer) as text

end if

set dateStr to ((year of now) as text) & monthStr & dayStr

return dateStr

end datePart

on clientCode()

choose from listclientCodeListwith title "Client Codes"

if the result is not false then

return item 1 of result

else

return "NIL"

end if

end clientCode

on projectCode()

choose from listprojectCodeListwith title "Client Codes"

if the result is not false then

return item 1 of result

else

return "NIL"

end if

end projectCode

on subProjectCode()

choose from listsubProjectCodeListwith title "Client Codes"

if the result is not false then

return item 1 of result

else

return "NIL"

end if

end subProjectCode

on partCode()

choose from listpartCodeListwith title "Client Codes"

if the result is not false then

return item 1 of result

else

return "NIL"

end if

end partCode

on appUsedCode()

choose from listappUsedCodeListwith title "Client Codes"

if the result is not false then

return item 1 of result

else

return "NIL"

end if

end appUsedCode

Well, I think I found out why the services weren't working - AppleScriptObjC uses some hacks magic in order to call Cocoa methods using a variation on the AppleScript handler naming convention, but the Services API looks for a method with an Objective-C signature. I'm not sure if something changed in Mountain Lion, since I've seen service examples for both ASObjC and MacRuby, but I wasn't able to get them to work due to the method not being found. Setting up an Objective-C skeleton did work, so it looks like a service is doable, although I have some code rearranging to do.