A'ware FAQsFrequently-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?
If you want the Authorware piece to remain in the same browser window, this works best:
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.
Another option is to launch the Authorware file in the same browser window and use:
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!
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:
Beware of text wrapping and unwanted <br> tags when copy/pasting.
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.
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
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)
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.
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.
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
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.
Yes, and in a great, accessible, and 'wiki-like' way.
If the audio plays but there's no video, it's almost surely a codec problem.