A'ware Tips - FAQs to help with your Authorware project

Using Authorware's ReadURL function, you can invoke javascript to effect the web browser which contains the web-packaged Authorware piece.

One option is to use javascript to launch a new window with the HTML that embeds the Authorware file, then use:
ReadURL("javascript:window.close()") or ReadURL("javascript:self.close();")
in the Exit button to close that browser window.

If you want the Authorware piece to remain in the same browser window, this works best:
ReadURL("javascript:history.go()")
in the Exit button so the browser is redirected to the previous webpage that contained the link that launched the Authorware file.

However with the 2004 web player that second option doesn't work as it did before- it seems the initial player (a type of 'stub loader') is its own page, which then launches the actual player and Authorware file in a new page.
So just going back one page will redirect to that stub loader, which then reloads the Authorware file. In that case, use:
ReadURL("javascript:history.go(-2)")
to go back 2 pages at once.

Another option is to launch the Authorware file in the same browser window and use:
ReadURL("javascript:history.back()")
in the Exit button so the browser is redirected to the previous webpage that contained the link that launched the Authorware file. However, this method hasn't proven as reliable.

Finally, if you must close a web-packaged Authorware piece that is in its own window that was not opened using javascript, refer to:
http://www.aspalliance.com/peterbrunone/impossible.asp
Where javascript within the browser of the web-packaged piece will assume 'parent' status, allowing the ReadURL code to execute without the dialog box. Here's the code to place within the HTML page itself:

<SCRIPT LANGUAGE="JavaScript">
window.opener = top;
</SCRIPT>

Don't forget, Authorware's NetConnected variable is a great way to implement the ReadURL code or a simple quit() in the Exit button of a piece that is delivered for both the web and local delivery!

Ron Lubensky has developed a few cool tools for Authorware, one being the "JavaScript Quick Reference". Check out his website for this and other great A'ware Commands. Below is an excellent reply, posted with his permission, to a similar question on the Authorware newsgroup:

As much as I enjoy and am productive using JS in AW, in my opinion novice authors should familiarise themselves with AW's classic scripting language first. This is because most documentation and archived posts on AWARE and this newsgroup use this. Also, as has been pointed out elsewhere, the current implementation of JS does not cover all corners of AW. For example, expressions placed in various property fields (eg Active If on a response) must be given in classic AW scripting syntax.

But the main reason I would recommend to you that you start with classic AW scripting is that the script editor is able to perform syntax checking immediately for you--you literally can't close the editor until it makes sense.

In addition, your use of Authorware user variables is determined at design time. When classic scripting, if you reference a variable unknown to Authorware, you automatically get a "New Variable" dialog up prompting you to instantiate it in Authorware's internal name table.

With JS there is no syntax or variable checking until you run the piece. This makes debugging more challenging.

Furthermore, there is no relationship between variables instantiated in JS and user variables created in native AW. So if you have an icon like a perpetually-positioned motion icon which is driven by a JS variable, you have to reference it in the icon property field through the EvalJS() function, or else programmatically shift the JS variable into an AW variable.

Also, classic Authorware user variables exist for the life of your piece, from beginning to end. JS variables only exist from the point where they are declared in a "var" statement or assigned a value. This makes the useful authoring trick of Running from Flag a bit trickier if you haven't organised your code well enough.

The built-in functions and variables (and also user variables) are presented to JS through an object referenced as "aw". For example, to get AW's UserName variable into JS, the JS script should refer to aw.UserName. This works very well, but is an extra layer of complexity for novice scripters.

Lastly, the scripting of external functions in u32s or xtras is not possible directly from JS. Such calls must be made through a call to aw.Eval(). Again, this precludes syntax (eg typo) checks at design time.

Now, I am committed to scripting in JS and have no difficulty with the above issues. In fact, I have written a set of JS methods for myself which in many respects work around them. Future versions of AW may improve the integration of JS in AW, but for now we have to accept the above issues.

Concentrate on the concepts behind the syntax and you will find it easy to adapt from languages you already know. Once you are comfortable with this, then move on to JS to gain its unique benefits.

Authorware 7.02 (the latest at the time of this writing) cannot yet generate the proper HTML code for the 2004 Web Player. Perhaps an update will be released which allows for that, or maybe some kind soul will create a substitute command, or maybe we'll have to wait for Authorware 8!

Until then, Paul Swanson dug into Macromedia's website code and found the proper codebase for the 2004 web player ActiveX install:
*Updated for the latest player version

Beware of text wrapping and unwanted <br> tags when copy/pasting.
Replace 'MapFile.aam' with the name of your .aam file.
Don't forget your height and width parameters!

With the advent of IE 6 (and perhaps 5.5), the way linked-to windows appear has been changed. Now all such windows appear behind the active browser window, which in the case of Authorware and web-based programs, can be quite inconvenient at times. The following solution is not my own, but pulled from discussions in the Authorware newsgroup. Credit belongs to those who found the solution (search the A'ware archives for such if interested).

To move a browser window to the front, use functions from Xtra version of BuddyAPI:

Example GoToNetPage code
GoToNetPage("http://www.awaretips.net","_blank")

Immediately after the calculation that contains a similar function call as above, insert a .5 second wait here to allow the browser window to initialize (timing may depend on system specs of user's machine). Then place the following code in a calc below that wait icon.

window_var:= baWindowList("IEFrame", "", 0)
window_handle := ValueAtIndex(window_var, 1)
baWindowToFront(window_handle)

First all IE browser windows are found (there will be at least two, the one for the A'ware applicaiton, and the one just created - there may be others, but the new one will be listed first). That first window is then moved to the front.

For the Mac crowd, Andrew Boyer has written an equivilent of the cover.u32 for the Mac - appropriately titled Cover.xcmd. If you find this useful, visit Andrew's site and drop him a thank you note. The source (C)for this xcmd is also available on his website. An excerpt:

"Cover.XCMD is a MacOS version of the Cover UCD Adobe includes with recent versions of Authorware. Using Cover.XCMD allows you to author cross-platform pieces using the Cover() function without needing to make any special provisions for Mac compatibility."

The cover.xcmd is mirrored on this site, but is available from Andrew's site here. You should download this xcmd directly to a Mac if you have that option. Visit Andrew's site for the latest on compatibility. This XCMD will likely not work under OS X

		A'ware FAQs Frequently-Asked Questions regarding Authorware. These are a compilation of issues we've discovered during development as well as excellent insights made be regulars of the Authorware forum and listserve. Click any question below to reveal the answer. Check the Other Sites page if you don't find your answer here.

		For a web-packaged piece, how can I program the Authorware application to close the browser window in which it is contained? Using Authorware's ReadURL function, you can invoke javascript to effect the web browser which contains the web-packaged Authorware piece. One option is to use javascript to launch a new window with the HTML that embeds the Authorware file, then use: ReadURL("javascript:window.close()") or ReadURL("javascript:self.close();") in the Exit button to close that browser window. If you want the Authorware piece to remain in the same browser window, this works best: ReadURL("javascript:history.go()") in the Exit button so the browser is redirected to the previous webpage that contained the link that launched the Authorware file. However with the 2004 web player that second option doesn't work as it did before- it seems the initial player (a type of 'stub loader') is its own page, which then launches the actual player and Authorware file in a new page. So just going back one page will redirect to that stub loader, which then reloads the Authorware file. In that case, use: ReadURL("javascript:history.go(-2)") to go back 2 pages at once. Another option is to launch the Authorware file in the same browser window and use: ReadURL("javascript:history.back()") in the Exit button so the browser is redirected to the previous webpage that contained the link that launched the Authorware file. However, this method hasn't proven as reliable. Finally, if you must close a web-packaged Authorware piece that is in its own window that was not opened using javascript, refer to: http://www.aspalliance.com/peterbrunone/impossible.asp Where javascript within the browser of the web-packaged piece will assume 'parent' status, allowing the ReadURL code to execute without the dialog box. Here's the code to place within the HTML page itself: <SCRIPT LANGUAGE="JavaScript"> window.opener = top; </SCRIPT> Don't forget, Authorware's NetConnected variable is a great way to implement the ReadURL code or a simple quit() in the Exit button of a piece that is delivered for both the web and local delivery! Aware Script vs. Javascript - which is preferred? Ron Lubensky has developed a few cool tools for Authorware, one being the "JavaScript Quick Reference". Check out his website for this and other great A'ware Commands. Below is an excellent reply, posted with his permission, to a similar question on the Authorware newsgroup: As much as I enjoy and am productive using JS in AW, in my opinion novice authors should familiarise themselves with AW's classic scripting language first. This is because most documentation and archived posts on AWARE and this newsgroup use this. Also, as has been pointed out elsewhere, the current implementation of JS does not cover all corners of AW. For example, expressions placed in various property fields (eg Active If on a response) must be given in classic AW scripting syntax. But the main reason I would recommend to you that you start with classic AW scripting is that the script editor is able to perform syntax checking immediately for you--you literally can't close the editor until it makes sense. In addition, your use of Authorware user variables is determined at design time. When classic scripting, if you reference a variable unknown to Authorware, you automatically get a "New Variable" dialog up prompting you to instantiate it in Authorware's internal name table. With JS there is no syntax or variable checking until you run the piece. This makes debugging more challenging. Furthermore, there is no relationship between variables instantiated in JS and user variables created in native AW. So if you have an icon like a perpetually-positioned motion icon which is driven by a JS variable, you have to reference it in the icon property field through the EvalJS() function, or else programmatically shift the JS variable into an AW variable. Also, classic Authorware user variables exist for the life of your piece, from beginning to end. JS variables only exist from the point where they are declared in a "var" statement or assigned a value. This makes the useful authoring trick of Running from Flag a bit trickier if you haven't organised your code well enough. The built-in functions and variables (and also user variables) are presented to JS through an object referenced as "aw". For example, to get AW's UserName variable into JS, the JS script should refer to aw.UserName. This works very well, but is an extra layer of complexity for novice scripters. Lastly, the scripting of external functions in u32s or xtras is not possible directly from JS. Such calls must be made through a call to aw.Eval(). Again, this precludes syntax (eg typo) checks at design time. Now, I am committed to scripting in JS and have no difficulty with the above issues. In fact, I have written a set of JS methods for myself which in many respects work around them. Future versions of AW may improve the integration of JS in AW, but for now we have to accept the above issues. Concentrate on the concepts behind the syntax and you will find it easy to adapt from languages you already know. Once you are comfortable with this, then move on to JS to gain its unique benefits. Can OBP generate the HTML code for the 2004 Authorware Web Player? Authorware 7.02 (the latest at the time of this writing) cannot yet generate the proper HTML code for the 2004 Web Player. Perhaps an update will be released which allows for that, or maybe some kind soul will create a substitute command, or maybe we'll have to wait for Authorware 8! Until then, Paul Swanson dug into Macromedia's website code and found the proper codebase for the 2004 web player ActiveX install: Updated for the latest player version <object classid="CLSID:15B782AF-55D8-11D1-B477-006097098764" codebase="http://fpdownload.macromedia.com/get/shockwave/cabs/ authorware/awswaxd.cab#version=2004,0,0,73"> <param name="SRC" value="MapFile.aam"> <embed src="MapFile.aam" pluginspage="http://www.macromedia.com/shockwave/download /index.cgi?P1_Prod_Version=AWPfull" type="application/x-authorware-map"> </embed> </object> Beware of text wrapping and unwanted <br> tags when copy/pasting. Replace 'MapFile.aam' with the name of your .aam file. Don't forget your height and width parameters! I need an installer, but InstallShield and such are too expensive. Alternatives? Many developers report excellent results with InnoSetup. It comes with an ISTool front-end for customization. And hey, it's FREE! Support newsgroups can be found here. How can I cover the desktop with a color other than black? Authorware simply does not scale graphically. Thus, if the user's monitor is larger than the area defined for your application, the desktop will be shown outside the Authorware window. Most users know using the cover.u32 provided on the A'ware CD will cover these surrounding areas in black - but black can be so boring. So some kind soul developed the RGBcover.u32. I don't know to whom the credit belongs but this .u32 has been in the public arena long enough, and requests are frequent enough, it should be alright for me to provide this colorful .u32 from here. How do I prevent the resulting window from appearing behind the Authorware-web window when I use GoToNetPage? With the advent of IE 6 (and perhaps 5.5), the way linked-to windows appear has been changed. Now all such windows appear behind the active browser window, which in the case of Authorware and web-based programs, can be quite inconvenient at times. The following solution is not my own, but pulled from discussions in the Authorware newsgroup. Credit belongs to those who found the solution (search the A'ware archives for such if interested). To move a browser window to the front, use functions from Xtra version of BuddyAPI: Example GoToNetPage code GoToNetPage("http://www.awaretips.net","_blank")* Immediately after the calculation that contains a similar function call as above, insert a .5 second wait here to allow the browser window to initialize (timing may depend on system specs of user's machine). Then place the following code in a calc below that wait icon. window_var:= baWindowList("IEFrame", "", 0) window_handle := ValueAtIndex(window_var, 1) baWindowToFront(window_handle) First all IE browser windows are found (there will be at least two, the one for the A'ware applicaiton, and the one just created - there may be others, but the new one will be listed first). That first window is then moved to the front. How can I implement Microsoft's Agent technology into Authorware? This is not a simple task, but Steve Gannon of Gantek Multimedia has an excellent example on his site in the Downloads section. Authorware Amy's site may have resources for this implementation as well. How can I cover the desktop on a Mac? Is there a Cover XCMD for the Mac? For the Mac crowd, Andrew Boyer has written an equivilent of the cover.u32 for the Mac - appropriately titled Cover.xcmd. If you find this useful, visit Andrew's site and drop him a thank you note. The source (C)for this xcmd is also available on his website. An excerpt: "Cover.XCMD is a MacOS version of the Cover UCD Adobe includes with recent versions of Authorware. Using Cover.XCMD allows you to author cross-platform pieces using the Cover() function without needing to make any special provisions for Mac compatibility." The cover.xcmd is mirrored on this site, but is available from Andrew's site here. You should download this xcmd directly to a Mac if you have that option. Visit Andrew's site for the latest on compatibility. This XCMD will likely not work under OS X What is the future of Authorware? Well, since the years-persistent rumour has now been realized, Authorware is apparently fully mature. Of course, that's a bunch of bunk since it cries for several improvements. But, it is still a valid application with a few more years left as an elearning tool. So while no more updates will be made, Adobe will - for now - still sell and support it. What's the future? I'd LOVE to see an Authorware-like IDE on top of Flex. We'll see. Til then, seems like Adobe is pushing lite-users to Captivate (phooey) and heavy users to Flash. So time to get moving on those new skills! RIP, Authorware, you did us well for many years. Is the Authorware manual online? Yes, and in a great, accessible, and 'wiki-like' way. Checkout the LiveDocs implementation of the Authorware 7 manual. My Windows Media movies play sound but I can't see the video! If the audio plays but there's no video, it's almost surely a codec problem. Download the Microsoft Windows Media Player codec pack to see if that resolves the issue. If so, you will need your audience to install this these codecs on their computer to view your videos correctly. Collapse All...