To display dialogs from the command line I just use
$ osascript File.scpt
However, the progress bar feature isn't constrained to a dialog window because it adapts to the current application, e.g. a Finder window, where the progress updates are shown on the bottom of the window. File.scpt would look something like this.
set numUpdates to 100
set progress total steps to numUpdates
set progress completed steps to 0
set progress description to "Updating..."
set progress additional description to "Preparing to process."
set cycle to 1
repeat with a from 1 to numUpdates
# update description, completed steps, etc
end repeat
When I run my script from a terminal window, however, the script runs but nothing is shown to indicate the progress. Is there a way to force the progress bar to open as a new dialog or something along those lines without having to export the script as a ".app" file?
The reason Script Editor can display progress in its window and Terminal cannot is because Script Editor has its own extended scripting definition with the extra functions so when the script is run via script editor it has been programmed with the extra progress indicator but no other applications are sorry. The way I see it, you pretty much have 2 ways I can think of that will let you display "Progress" in AppleScript:
This is kinda ugly but I used to just have a transparent spinner gif file that will be displayed in a dialog which will give the affect that something is loading or working. and a single button saying Nothing or OK eg.
display dialog "Loading..." buttons:{"OK"} with icon ("/path/to/loader.gif" as POSIX file)
And if you wanna make it temporary just add giving up after (duration in seconds)
This is probably the best option but it is probably more complicated. I advise that you transfer to a programming language called "AppleScript Objective C" otherwise known as "Cocoa AppleScript". This allows you to use the basic AppleScript commands with Cocoa Windows/Dialogs/etc including progress bars!. to start you off you should download Xcode and research AppleScript Objective C and perhaps stick to it. Its better than AppleScript but still has the same functions :)
Related
( I have been pushed to an obvious answer to my "Mystery" from a friendly member here.
I feel a little ashamed not to have found this solution myself, but will leave this posting online if there aren't too many irritated folks around. Maybe someone else can learn from this … apologies to every "know-it-alls"!)
I have recorded these actions with Automator:
– Cmd-tab to bring TextEdit to front (must have some lines typed)
– Pressed left arrow 7 times using shift down
– Stopped the recording
Next I selected and copied (Cmd-c) all action icons in Automator's "Record my actions" window.
I switched to Script-Editor and pasted (Cmd-v) them into a new window.
Then, I repeated above recording with 3 times UP arrow and copied icons into another new window.
I took only the two "set uiScript to …" lines and appended them in the first script.
THEY READ IDENTICAL:
set uiScript to "keystroke \"\t\" using command down"
my doWithTimeout(uiScript)
set uiScript to "keystroke \"\" using shift down" -- 7 times left-arrow
my doWithTimeout(uiScript)
set uiScript to "keystroke \"\" using shift down" -- 3 times up-arrow
my doWithTimeout(uiScript)
on doWithTimeout(uiScript)
set endDate to (current date)
repeat
try
run script "tell application \"System Events\"\n" & uiScript & "\nend tell"
exit repeat
end try
end repeat
end doWithTimeout
(To make resulting code more readable I omitted error code and "delays".)
Now, if I disable one of the "keystroke" lines (=> --my doWith…) the script somehow knows that it either has to do Shift-leftArrow 7 times OR Shift-upArrow 3 times.
I tried this after computer restart, even copied the code from this web page and pasted it into a new Script Editor window – it still knew what to do!
HOW CAN THAT BE ???
My only idea is: there must be some internal Applescript database that recognises content even if copied/pasted.
Does anybody know ?
Only if I re-write the code identically will there happen NOTHING – until I copy the first line of either recording ("set uiScript to …"). So the information must be linked to this first line somehow.
(BTW: first two lines that bring TextEdit –or, e.g. a Finder window– to the front work only from opened Script Editor; you have to bring TextEdit to the front yourself, if you start the saved-as-program script from Script-Editor's menu icon subfolder. Nevertheless the script won't work without them…)
It "knows" because the keystrokes are in the string - keystrokes using control type keys (such as arrow keys) just don’t have a text representation, so they wind up being invisible. Some text editors such as BBEdit can show these invisible characters, but they don’t show up in the Script Editor.
Apple has obviously made Automator's Watch Me Do action able to capture some of these control keys in a string, but for the rest of us it is more difficult, since the control keys will actually perform their function when pressed. If you need to use these kinds of keys, the key code command can be used, since it refers to the actual keyboard key, for example:
tell application "System Events"
repeat 3 times
key code 126 using shift down -- up arrow
end repeat
end tell
As the answer is quite simple but may still be interesting to some, I'll explain it shortly:
red_menace (in his comment above) pointed out that strings may contain invisible elements (like arrow keys), therefore I next checked the obvious:
If you "cursor-walk" along the "set uiScript …" strings the cursor will actually "pause" for 7 or 3 "steps" respectively on its way.
I hadn't thought/heard of any "invisible" string-chars (apart from obvious ones in Word etc.).
I am trying to write a small AppleScript that can output a string of text which can be manipulated by another script. This works:
tell application "SpeechRecognitionServer"
set display to no
set theResponse to listen for {"yes", "no"}
if theResponse is "yes" then
display
else
say "Goodbye."
end if
end tell
The only problem is that it repeats the command that you issue it! (in our case, yes or no). So my question is: Is there a way to prevent it from repeating the command? I just do not see why it repeats the command, nor can I figure out which process runs the voice or I would just kill it.
Thanks
Manual fix:
System Preferences -> Speech -> Speech Recognition Tab
Disable the "Upon Recognition" checkbox.
Programatic fix:
This involves disabling these prefs before your code and then setting them back to their original values afterwards. That is, if you intend for this code to be portable to other users. If its only a personal script for yourself, then the manual fix is fine to set it permanently.
Refer to this forum for people asking the same question, and the various approaches they have tried:
http://macscripter.net/viewtopic.php?id=33259
I've got emacs in front of me.
I've run a find-grep, and it's got many hits, which are displayed in a window. The file names are displayed in green as hyperlinks.
I make that the only window, with C-x 1.
If I click on a file name, the window splits vertically, and the file with the found text is displayed in the other window.
If I click on further filenames, then the new file replaces the old file, which is what I want to happen.
So far, so good...
However if I resize the windows, then emacs will periodically (when I click) split one of the two windows again, rendering the display difficult to read. It will then cycle opening new files between the two new windows. Occasionally it will open more windows and make the situation worse. If I close any of these new windows they just get reopened again.
In fact sometimes this perverse behaviour happens even if I don't resize anything. It just seems to happen more often if I do.
I would like emacs to stop buggering around and just have one find-grep window and one 'display' window, and always replace the display window with the new file. I would also like to be able to set these windows to the sizes that seem most convenient.
Is there any way to achieve this?
Or can anyone point me to an essay on how the whole (replace the contents of this window/replace the contents of a different window/create another window by splitting) thing works, so I can go and hack it sane.
Short fix:
Try doing this
(setq split-height-threshold nil
split-width-threshold nil)
This will prevent Emacs from splitting windows automatically (horizontally or vertically). This might be undesirable in other situations, but this should do the job. Try it for a week or so and see if it disrupts your flow.
Also, I found that if the point was in one of the windows, and I clicked on a link, the file opened up in the next window (if any).
So, if you want to make the file open in the right window (when you have more than one window), you can ensure that the point is in the window before the window you want.
Longer answer:
OK. I was able to reproduce the problem. The thing is the window showing the files is pretty big (wide or tall) because you resized it and Emacs sees that the width or height is greater than the respective threshold and splits it likewise. So, we have to either make the threshold higher or disallow the behaviour completely.
And, just to answer the last few questions:
To get current window - (selected-window)
To get next window - (next-window)
To select a window - (select-window foo-window)
To get the buffer of the current window - (current-buffer)
To get the buffer of some window - (window-buffer foo-window)
To set a buffer for a window - (set-window-buffer foo-window bar-buffer)
I'm sure you can hack together decent window/buffer management functions using these functions.
You can use C-h f to get more details on each of these functions.
Also check out the Elisp manual - http://www.chemie.fu-berlin.de/chemnet/use/info/elisp/elisp_26.html
The problem I face is this:
I would like to have in a context menu (when i right-click on a folder) an action to be executed and display the output to the user, inside, let's say, a text area window with a vertical scrolling bar. Suppose, that the action is just a shell script that executes a "find" command inside the given directory, searching for a specified pattern.
I have managed to implement it, up to this point, using Automator. What I cannot do is to pipe the output in a synchronous fashion (what is meant by "synchronous" is to have the output print to the user when is produced by the "find" command, and not after the command has finished) in a GUI.
I have spent sometime searching on this and I have come to the conclusion that XCode and Interface Builder have to be put into the play? Am I on the right track? Is there a straightforward and simple way in succeeding in this without having to dig into this framework?
Thank you very much,
Babis
You can have the shell script throw a dialog when it gets the result using http://cocoadialog.sourceforge.net/
In emacs I have various functions to manipulate text. Now that I'm using xcode, I suppose I could make emacs my default editor, but I want to browse obj-c objects and such, so I'd rather just implement my most used text manipulation commands for xcode.
First on my list, I'd like a command that moves the text of the current line up/down one line, keeping the cursor on the current line.
In emacs this is:
(defun move-one-line-downward ()
"Move current line downward once."
(interactive)
(forward-line)
(transpose-lines 1)
(forward-line -1))
I'd be happiest if I could write a script in Python that would do the equivalent in XCode, but as far as I can tell, I need to talk to AppleScript to do this.
Can someone walk me through how to do this with XCode?
Xcode 4 has a new set of command for moving the line where the cursor is or the selected text with command + option + [ or ]
⌥⌘[ or ⌥⌘]
http://developer.apple.com/library/mac/#documentation/IDEs/Conceptual/xcode_help-command_shortcuts/MenuCommands/MenuCommands014.html
What you’re wanting to do can be achieved through Xcode’s “User Scripts”—and it helpfully comes with a pair of scripts that almost do what you want. (I’m using Xcode 3.2 here, but I think these were also there in 3.1)
Look in /Developer/Library/Xcode/User Scripts/; there are two applescripts there, Move Line Up.scpt and Move Line Down.scpt. Here’s what’s in Move Line Up:
(*
To edit this script, choose Save As... and save it in your home directory, then re-add it to the User Scripts list.
*)
using terms from application "Xcode"
tell first text document
set {startLine, endLine} to selected paragraph range
if startLine > 1 then
set theText to (paragraphs startLine through endLine)
set theText to (theText as string)
delete (paragraphs startLine through endLine)
make new paragraph at beginning of paragraph (startLine - 1) with data theText
set selected paragraph range to {startLine - 1, endLine - 1}
else
beep 1
end if
end tell
end using terms from
These almost do what you want, except they select the whole line afterwards; I’m no applescript expert, but you probably want to store the selected character range. Have a look at the Xcode scripting dictionary (in AppleScript Editor, File -> Open Dictionary -> Xcode) to find out the types of objects you can manipulate.
You can add your own scripts to Xcode with the “Edit User Scripts”menu item in the script menu; and assign shortcut keys to the scripts in that window also, by double-clicking in the right-hand column beside the entry for the script menu item.
You can also use shell scripts (perl, python, bash, whatever) in the User Scripts menu, but these process only the selection or the whole file, so might be a bit heavyweight for moving a single line up or down.
See all the docuemntation on User Scripts here: http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/XcodeWorkspace/310-User_Scrips/user_scripts.html
I hope this helps!
I think your question is more generic that Xcode/emacs. Most IDE can't do stuff that editors can do and vice versa.
What I do is to use Xcode for 'simple' stuff and compile/debug. When I want to do lot's of coding (hm ... text editing) I open multiple files in one Vim (no offense to emacs ... vim is my editor of choice) and use all the vim tricks available.
I follow the same process when I need to do lots of coding on Windows (Visual Studio). I have VS opened just for compiling/debugging but I do most coding in separate Vim window.
I don't need to do any of that on Unix because I just open file in Vim and run Makefile from within Vim, jumping directly to errors and so on (:mak) ...
I'm sure that there are some extremely clever things to get Xcode do stuff that are already in Vim and Vim to do stuff that Xcode can do but I'm focusing on coding so not much time to play around.
Also, you can hook up emacs (or vi, or bbedit, or ed, I imagine) to xcode, so that they will talk to each other. When you tell xcode to open a file it will call emacsclient, etc. You can even get emacs to tell xcode where to put a breakpoint (I don't remember how, but I asked a question here a while back, and it works great)