[noam]

I'm trying to get Netscape to print via Applescript. I'm using Sandi's Additions, but whenever I try to run my script, I get an error on the line 'TypeText "p" with Command'. The error is 'Expected end of line, etc. but found ". '

Any ideas how to get Script Editor to stop barfing on this? (Or, any other ideas on how to get Netscape to print a page!!???)

Thanks!
Noam

[SillyPooh]

For some odd reason - read: bad AS implementation -, Communicator doesn't understand the print command at all.

I can't help you with Sandi's either. But you might get the "Menu Events Scripting Addition" which is just what you need...

[Paul Crawford]

Hi all,

Actually, Netscape Communicator does understand the Print command, just not for windows. ;-) Instead, its Print command works for lists of file specs (sort of the bare minimum requirement for that Apple Event).

Noam, if you'd still like to try using the Sandi's Additions OSAX (which is a simpler tool than the more powerful Menu Events INIT + OSAX combo mentioned above by SillyPooh), it might still be possible to do so. In fact, I have used a similar automated printing technique successfully in Communicator, with Sandi's Additions.

I guess it's possible that the AppleScript error message is actually due to a previous obscure syntax mistake, on an earlier line, which is only being detected/reported on the 'TypeText ...' line. You could try running with just the 'TypeText ...' line by itself (inside the 'tell app "Netscape Communicator™" / end tell' block).

Otherwise, the problem could be that Sandi's Additions is not being properly loaded/recognised for some reason. You could try the following approaches:-

• Run with just the 'Base' set of system extensions.
• Increase the Script Editor's memory partition to 4 MB or more.
• Move Sandi's Additions out of your System Folder's 'Scripting Additions' subfolder, them move it back in.
• Download a fresh copy of "Sandi's Additions" from MacScripter's Scripting Additions library.
• Move any other third-party OSAXen out of your System Folder's 'Scripting Additions' subfolder (to rule out any possible interference from other OSAXen).

If by some miracle it starts working, then you're home free. :-)

BTW, if you also want to automatically select the Print dialogue's 'OK' button (by simulating a press of the <Return> key), then I've found that it's best to do it all with one 'TypeText' command, rather than with two separate ones. (When the modal Print dialogue appears, it seems to block further script commands.) I.e., just append a 'return' to the "p" string, as in:-

Code:
TypeText ("p" & return) with Command

Regards, and good luck,

--Paul

[This message has been edited by Paul Crawford (edited 12-01-2000).]

[noam]

Paul,

Thanks so much for your very helpful response. I plugged in the code snippet you recommend, and the parentheses seem to have helped but not solved the situation. Now the error I get is

A Command:true can't go after this TypeText(p & return).

I'll try some of the other suggestions you have. Any further ideas?

If Netscape can print files but not windows, would it be possible for me to print the web page if I first save it as a file, and if so what is the syntax of the file list?

Thanks!
Noam

[Paul Crawford]

Hi again,

Sorry for the rather rambling length of this reply, but I wanted to discuss some of the drawbacks with Communicator 4.x's 'print' command, as well as a few more wild ideas about how to "debug" the persistent problems you're encountering with Sandi's Additions. So, here goes...

1) Sandi's Additions woes:
It's beginning to look more and more like there's some strange issue (perhaps even a disguised syntax mistake on an earlier line as I speculated in my last post), unrelated to Sandi's Additions, that's causing AppleScript to generate a misleading error message at the 'TypeText ...' line. From this new error message, it almost seems as if AppleScript isn't recognising the word 'TypeText' as a scripting-addition command at all, but rather is interpreting it as a user-written subroutine to which the '"p" & return' string is being passed as a parameter... ?

Have you been able to save a compiled version of your script, or is the error preventing you from saving it as anything other than text? If it has been compiled, is the word 'TypeText' displayed with the formatting appropriate to the 'Application keywords' category (as shown in the Script Editor's 'Edit | AppleScript Formatting...' command)? This might give a further clue as to how AppleScript is "seeing" this word.

Also, if you haven't already done so, you could try a quick experiment to verify whether the error is really being caused by Sandi's Additions. Open a brand-new, empty script window in Script Editor, and enter only the following lines:-

Code:
tell app "Netscape Communicator™"
	activate -- It's best to bring an app to the front before simulating keystrokes
	TypeText "p" with Command  -- Leave off the '& return' portion for now.
end tell

If this stripped-down script successfully brings up Netscape's Print dialogue, then you'll know that the problem isn't related to Sandi's Additions. On the other hand, if the same error message still occurs, then I'd recommend troubleshooting the installation/loading of Sandi's Additions (e.g.,, you could try the various approaches that I mentioned in my last post). Honestly, the 'TypeText' command can work fine, at least it does on my machine. :-) [BTW, just for comparison purposes, my copy of Sandi's Additions is version 1.2 (July 14, 1995; 9594 bytes), and I'm running under Mac OS 9.0.4 and AppleScript Update 1.4.3, on an older beige PowerMac G3/266/128MB[RAM]/129MB[VM].] If all else fails, try one of the alternative freeware OSAXen listed in MacScripter's OSAXen library that can perform a similar task (e.g., Eric Grant's Sigma's Additions).

2) Communicator's built-in 'print' command:
Yes, it's technically possible for a script to ask Communicator to load a web page and save it to disk, and then print the saved file (actually, the "print" step also involves reopening and re-rendering the file in a Communicator window before printing starts). The syntax of the 'print' command itself is relatively straightforward:-

A) 'print {(alias "pathname-1"), (alias "pathname-2"), ...}'.
B) 'print {(file "pathname-1"), (file "pathname-2"), ...}'.
C) 'print {"pathname-1", "pathname-2", ...}'.

Basically, you can supply a list of alias-specs or file-specs (or a list of 'alias' coercions or 'file' coercions of pathname strings), or just a list of the pathname strings themselves. Note that it's best to supply only one item in the list, for various reasons related to easier testing, some of which are explained below. And, one day, Netscape may even get around to letting us specify a URL or a window (gasp!) instead of a disk pathname to be printed, if they haven't already done so in Communicator 6 (?).

Unfortunately, with the Communicator 4.x version of the 'print' command, there are a few issues that could crop up unexpectedly. For instance:-

• A web page might typically contain partial URLs that link to images which are "local" to its website, but it might not include a 'BASE' tag in its HTML header to indicate the "root" URL. When such a page is saved to a file and then reopened in the web browser for printing, those image links would be unresolved (they'd appear as those "broken graphic" icons). One way to work around this issue is to insert the missing '<BASE HREF="web-page-parent-URL">' tag in the HTML header of the saved file, although doing this from a script would involve a fair amount of work. Fortunately, nowadays web pages from many major websites are a little more "download friendly"; they either include the required BASE tags, or they use full (complete) URLs to link to their images, or they dynamically render themselves "on the fly", etc.
  
• Another scripting issue that crops up in the retrieval of a web page to a disk file, is that you'd need to wait for the file to be created and for the "download" to complete before invoking Communicator's 'print' command. (At least, when the web page is saved to disk for the first time. Otherwise, Communicator might attempt to print a non-existent or partial file.) Checking for download completion could be done via many methods, including the use of the Finder's 'exists' command, and/or the recently-introduced 'busy status' field of the 'info for' command (of Apple's Standard Additions OSAX), and possibly by querying Communicator itself. [However, the "good" news is that once the web page has finished downloading, you could then simply issue the 'print' command. The 'print' command automatically takes care of everything else:- the reopening of the file into a window, the re-rendering of the file, and then (the initiation of) the actual printing.]
  
• Possibly the most serious issue with this approach (from a scripting point of view), is that Communicator's 'print' command eventually brings up the same old Print dialogue, waiting for someone to press the 'OK' or 'Print' button! Essentially, you'd be back to square one. So, even if the entire convoluted process -- starting the download, waiting for completion, and then printing (at least, starting to print) -- works well, the script would still need a way to simulate clicking that stubborn 'OK' or 'Print' button. Some folks rely on system extensions that can "auto-dismiss" dialogues (e.g., the old standby, Okey Dokey Pro). [Of course, other web browsers may very well be more "print friendly" than Communicator, although I personally haven't tried automating the printing process in MS IE, or iCab, etc.]

Let us know if you still wish to explore this alternative route. There might already be some relevant web-printing scripts available in MacScripter's 'Script Of The Week' library. I also have a small Communicator script of my own that could be used to automate saving a web page to disk & issuing the 'print' command, and I could post it here if you wish. Remember, though, that there's always that pesky 'OK' or 'Print' button to worry about. ;-)

Regards,

--Paul

[This message has been edited by Paul Crawford (edited 12-03-2000).]

[noam]

OK,

Duh. I finally figured out the problem with Sandi's additions. I'd put it in the wrong Scripting Additions folder--the one in my Extensions folder, as the accompanying docs instructed, not my "blessed" Scripting Additions folder in the root of my System Folder. Duh again.

Anyway, so Typetext is now working... sort of. Currently my script reads like this:

tell application "Netscape Communicator™"
activate
OpenURL "http://www.yahoo.com"
TypeText "p" with Command
end tell

However, when I run it, it seems to skip over the Typetext line because it's still loading the page. If I put in 6 identical Typetext lines, it eventually picks up the last 1 or 2... However, that's not elegant or reliable. Is there a way I can pause execution of the script until the page is loaded (even if it just means telling the script to wait 3 seconds before proceeding)?

Thanks!
Noam

[Paul Crawford]

Hi again,

Great news! I'm glad that this mysterious issue with Sandi's Additions turned out to have a simple solution. :-)

Yes, it's possible to have your script wait in a not-too-kludgey way for the page to finish loading. Communicator has a built-in window property called 'busy' which comes in handy for this purpose, in conjunction with AppleScript's 'delay' command (the latter was introduced as a standard in Mac OS 8.5+). You could try something like what I used to do:-

Code:
tell application "Netscape Communicator™"
	activate
	OpenURL "http://www.yahoo.com"
	
	repeat while ((busy of (window 1)) > 0)
		delay 1 -- Give some time to other apps while page is loading
	end repeat
	delay 1 -- Extra wait for the 'Print..' menu-item to become enabled (might be unnecessary?)
	
	TypeText "p" with Command -- Or, use '("p" & return)' to auto-accept the Print dialogue
end tell

Let us know how things turn out. We wish you "happy printing"!

Regards,

--Paul

[This message has been edited by Paul Crawford (edited 12-06-2000).]

[noam]

Paul,

You rock! It works like a charm. One more detail: I'd like to put a delay immediately after the "activate" step so that, in case Netscape wasn't open when the script starts, it has time to open before the script proceeds. How do I do this?

Thanks again,
Noam

[Paul Crawford]

Hi again,

I'm glad that things turned out well with the web-page loading & printing. :-)

In theory, if an app isn't already running, you shouldn't need to do anything special to get your script to wait until it has been launched/activated. AppleScript usually needs to wait for the app to finish launching so that it could send the activate event to the app. However, reality is quite often different from theory ;-), so if you want to be sure and explicitly wait for the app to be launched/activated, try using either of the two methods shown below. The first method relies on the 'path to frontmost application' command of the built-in Standard Additions OSAX; the alternative (and slower) second method uses the Finder's built-in '(get) application processes...' command. Either method could be used after the line containing the 'activate' command:-

Code:
tell application "Netscape Communicator™"
	activate
	
	-- Method #1
	tell current application
		repeat while ((path to frontmost application as text) does not end with "Netscape Communicator™")
			delay 1 --  Give some time to other apps while the desired app is launching/activating
		end repeat
	end tell
	
	(*
	-- Alternative (and slower) Method #2
	-- [2000/12/08 - Updated for better performance (my mistake) ;-)]
	tell application "Finder"
		repeat while ((name of (item 1 of (application processes whose frontmost is true))) is not ¬
			"Netscape Communicator™")
			delay 1 --  Give some time to other apps while the desired app is launching/activating
		end repeat
	end tell
	*)
	
	OpenURL "http://www.yahoo.com/"
	
	repeat while ((busy of (window 1)) > 0)
		delay 1 -- Give some time to other apps while page is loading
	end repeat
	delay 1 -- Extra wait for the 'Print..' menu-item to become enabled (might be unnecessary?)
	
	TypeText "p" with Command -- Or, use '("p" & return)' to auto-accept the Print dialogue
end tell

Or, just to add another twist, instead of using either method within the main portion of the script, you could try first detecting at the beginning of the script whether Communicator is running. If it isn't, you could explicitly launch it and wait for it to finish launching, and then go on to do the main stuff, something like this:-

Code:
-- If Communicator isn't already running, launch it and wait for it to finish launching
set theCommunicatorAppName to "Netscape Communicator™"
tell application "Finder"
	set theCommunciatorProcesses to (application processes where its name is theCommunicatorAppName)
end tell
if (theCommunciatorProcesses = {}) then
	tell application theCommunicatorAppName
		launch
		run
	end tell
	
	tell application "Finder"
		repeat while ((name of (application processes whose visible is true)) does not contain ¬
			theCommunicatorAppName)
			delay 1 --  Give some time to other apps while the desired app is launching
		end repeat
	end tell
end if
	
-- Do the main stuff	
tell application "Netscape Communicator™"
	activate
	
	OpenURL "http://www.yahoo.com/"
	
	repeat while ((busy of (window 1)) > 0)
		delay 1 -- Give some time to other apps while page is loading
	end repeat
	delay 1 -- Extra wait for the 'Print..' menu-item to become enabled (might be unnecessary?)
	
	TypeText "p" with Command -- Or, use '("p" & return)' to auto-accept the Print dialogue
end tell

As always, happy scripting!

Regards,

--Paul

[This message has been edited by Paul Crawford (edited 12-08-2000).]

[noam]

Paul,

Thanks once again. As you can tell, I'm a relative newbie to Applescript. Would you recommend any particular learning resources? It seems that most of the stuff I've found on the web is either extremely basic or reference-type material, neither of which really suits my learning curve. I'd prefer a structured but flexible tutorial that's geared towards technical users.

Thanks,
Noam

[Paul Crawford]

Hi again Noam,

Sad to say, much of what I initially knew about AppleScript I learned the hard way -- i.e., by trial and error after slogging through Apple's official AppleScript reference manuals, and the "dictionaries" of various scriptable apps. :-( However, eventually, via this Forum and other resources on the web, I also found several useful code snippets, as well as many good articles on avoiding both common and obscure pitfalls, and so on.

For pointers to these other resources, see the earlier related threads in this Forum (e.g., Where do I learn more., New to AppleScript and A good AppleScript book for newbie). In particular, check out Apple's downloadable AppleScript Guidebook Modules (for use with the Help system in Mac OS 8.6+), and the AppleScript Sourcebook's Tips section. Other tutorials & techniques of varying depth are also listed in MacScripter's Links - AppleScript Tutorials/How-to's section, and some useful books are listed in MacScripter's AppleScript Books section; explore as many as you can to find one that's right for you.

In terms of the official AppleScript reference manuals, they're not so bad really, and they do include many hard-to-figure-out-on-your-own techniques and code snippets. In case you don't already have them, they're downloadable from Apple's own AppleScript for Scripters web page. (Note: in the online frame-based "AppleScript Language Guide", you may have to scroll all the way down the left pane to the 'Other Links' section before you can see the 'Download PDF' link.)

BTW, many scripters (including myself, for that matter) are still more-or-less groping in the dark where AppleScript is concerned. Apple and the third-party vendors of major scriptable apps have never really promoted this technology in a consistent way, and there are also quite a few longstanding bugs from the ancient days of AppleScript 1.1 that have yet to be fixed [maybe they will all be resolved in the forthcoming Mac OS X? ;-)]. But with a growing community of independent scripters out there providing a network of support, we may not need Apple or the other big guys as much -- except to provide the core technology and the bug fixes, of course. :-)

[P.S.: I updated the "Method #2" in my previous post, as indicated there, to correct my oversight which made that method slower than it could be.]

Regards, and let us know from time to time of your further scripting adventures :-),

--Paul