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?
Hi,
Also, how are your scripts saved (compiled script, application, stay open, etc.).
gl,
kel
Hello.
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. 
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 "com.microsoft.Excel" to activate
else
set MSExcel to false
set AppProcess to "Microsoft Word"
tell application id "com.microsoft.Word" 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
try
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. 
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.
NoTabs,OneTab,PushTabs,IfTabs,PopTabs1Word,PopTabs2WordsHi Take318, McUsrll –
Thank you. I tried both recommendations separately and together, and they made no difference
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 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
…best, Mick
Hello.
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.
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.
…Mick
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?