Scripts require being open in the Applescript editor to run

Hello all-

I have a few scripts that require being open and told to run run via the Applescript editor to function right. Others I have do not. I can’t see the structural difference that’s causing this, but there must be one. What might I need to correct?

…best, Mick

Do your scripts use properties? That’s the only thing I can think of that could be influenced by whether or not you’re running it from the editor. (Well, “path to me” also behaves differently, but I’m guessing you aren’t using that to find your script editor.)

Is there any kind of pattern to how your scripts misbehave? What happens differently depending on how you run them?


Also, how are your scripts saved (compiled script, application, stay open, etc.).



And it wouldn’t hurt to see what a sample of one of them may look like.

I have one guess, and that is that some of the scripts are from pre Lion, and the format is wrong, but then I guess you would have been informed about the new format.

Thank you all–

take318: Yes, I do use properties. I don’t have to. I thought that was the best way to dim global variables, but I can change in a heartbeat. I’ll do so, and see what’s what. Why does this come to mind?

McUsrlll: Other than the topic, my code performs as I want when open in the editor, but here’s the top of it. The display dialog part runs. The “copy to the clipboard” part does not. When it works, it does a “Select All” then a “Copy” giving the visual feedback of everything as selected. Not so when closed. :frowning:

property TabSize : 3 -- spaces per tab.  Adjust to suit
property AlignDimAsToTabs : true -- Adjust to suit
property PutDimAsAtTab : 7 -- Adjust to suit
property NoTabs : {"Option Explicit", "Option Base", "Option Compare", "Sub", "Private", "Public", "Function", "Type", "Enum", "End Sub", "End Function", "#Const"}
property OneTab : {"Const", "Dim", "ReDim", "Static", "Stop", "Debug", "#If", "#Else", "#End"}
property PushTabs : {"For", "With", "Do", "Select", "Case"}
property IfTabs : {"If", "Else", "End If"} --Push, Pop & Push, Pop
property PopTabs1Word : {"Next", "Loop"}
property PopTabs2Words : {"End With", "End Select"}
property LineLeads : {"&", quote, "DQ"}
property MSExcel : true
set OldCode to ""
set NewCode to ""
set templine to ""
set Tabs to 0
set Stack to {1}
set CaseStack to {}
set TempStack to {}
set ThisLine to {}
set EqualsPosit to 0

set the clipboard to OldCode --This step works
display dialog "Please pick your application." buttons {"Cancel", "MS Word", "MS Excel"} cancel button 1 default button 3 with icon caution 
if result is {button returned:"MS Excel"} then
	set MSExcel to true
	set AppProcess to "Microsoft Excel"
	tell application id "" to activate
	set MSExcel to false
	set AppProcess to "Microsoft Word"
	tell application id "" to activate
end if

tell application "System Events" --This step only runs when open in the editor.
	tell application process AppProcess --scripting the GUI
		set frontmost to true
		set myList to (get name of windows)
		repeat with i from 1 to count of myList
				if last word of item i of myList is "Code" then
					perform action "AXRaise" of window i
					exit repeat
				end if
			end try
		end repeat
	end tell
	keystroke "a" using command down
	delay 1
	keystroke "c" using command down
	delay 1
	--if nothing happens, make sure your code window is frontmost.
end tell
...lots more code processing the clipboard.  Ends with a paste back.

I call the code from this script:

run script file "Macintosh HD 10.6:Applications:AppleScript:VBE.scpt"

Thanks, Mick

No need to lose the properties; they aren’t the issue. The reason they came to mind is they don’t have to be static. If you have a property that can be changed by running the script (for example, most of mine have one for the last folder saved to) then running the script from the editor often reverts the property to its original state. Properties are reset by the editor every time it compiles, and if this was the issue, it would mean that the code that updates your properties wasn’t working right. But again, that’s not what’s going on here.

I think the issue is AXRaise. I am woefully under informed on this class of actions, and it looks like you did everything correctly to me, but I’ve come across several posts from people complaining that AXRaise sometimes only brings the targeted window to the second position instead of the first. As a workaround, try selecting the window from the window menu of the application. The code should be:

click menu item (title of window i) of menu "Window" of menu bar item "Window" of menu bar 1

Try replacing “perform action “AXRaise” of window i” with that and see if it works. If it does, you can also rework your search loop to search the menu instead of the actual windows. Something like:

set myList to every menu item of menu "Window" of menu bar item "Window" of menu bar 1
repeat with myWindow in myList
	set myTitle to title of myWindow as text
	if myTitle ≠ "" then
		if last word of myTitle is "Code" then
			click myWindow
			exit repeat
		end if
	end if
end repeat

Curious to know if that fixes the problem.

There isn’t much to add to this. :slight_smile:

But if that doesn’t work, then I’ guess, that AppleScript somehow “sees” into your properties, and eyes reserved keywords, and adds a reference to itself for the script.

I suggest you turn the following properties into globals, so they aren’t declared at compile time, as long as their contents doesn’t change over the course, then locals would be more appropriate, as then there won’t be added any script context to them.


Hi Take318, McUsrll –

Thank you. I tried both recommendations separately and together, and they made no difference :frowning:

Looking at the menu in UI Browser, the menu-driven approach should be

menu item "1 Cell Merge.xls - CSS_Tablemaker (Code)"  of menu 1 of menu bar item "Window"  of menu bar 1

i.e. no menu “Window”. So I tried that, and it runs every so often :slight_smile: but very slowly. It’s stalling on that step. I haven’t been able to pick out the when.

As I was putting it in, I recalled that I’d been here before, and I had gone to the “AXraise” action because that got the window’s attention. The application here is MS’s Visual Basic Editor running from Excel, and it doesn’t play nicely with Applescript.

Not sure I have path forward :frowning:

…best, Mick


I don’ know if I’ll understand the problem fully until I run your actual code, and I’m on 2008 anyway.

There is however something you can try, if you suspect that VBA interferes somehow with AppleScript.

Say if you save your whole Applescript part as a separate script on disk.

Then from the part of VBA that usually started/triggered your script, you’ll have a little snippet like this:

run script "hfs:path:to:my:script:scpt"

That should start up a whole new scripting environment, I believe the line below to do the same, and that one is even better, as you are guarranteed to use the script runner that the system uses.

tell application "AppleScript Runner" to run script "hfs:path:to:my:script:scpt"

Of course you’ll have to modify your original script to regain the context, this time from the “outside” since Excel is just any other application when the original script starts up, but it may be worth a try. :slight_smile:

Hi -

The script isn’t triggered by VBA. It’s user triggered with the purpose of “prettifying” the code in a VBA module. And it’s started with a one liner scattered about so that the main code needs be in only one place. One-liner code is this:

run script file "Macintosh HD 10.6:Applications:AppleScript:VBE.scpt"

I’ll try your mod to that, but that is the way it only runs the top. In the editor environment I’ve tried without success to set the position of the windows. The UI-browser clearly shows me what to touch, but the VBE doesn’t play along.


If VBA is the problem and the script is user triggered, can you rewrite the script to bypass VBA? I’m assuming VBA already saves the code to a file somewhere, right? How about making the script into a droplet that processes that file directly?