andrewlucking.com

The folks at Macromedia are putting together an integration kit to help make Flash to Javascript communication (and vice versa) a little less ambiguous. They’ve provided a beta version here. Looks to be a pretty comprehensive project - supporting the passing of all the main datatypes on most common browser/os configurations. I think Christian and Mike deserve credit for identifying this as an area that could benefit from a standard (and encompassing) implementation.

Great timing too. I’ll probably try this out a bit in implementing the SCORM requirements for an upcoming project.

I’m catching up on my reading so this may be old news.

It looks like an alpha of mozilla.org’s Devmo site has gone live here:
http://developer-test.mozilla.org/
They’ve gone with a wiki format and have posted a list of the Netscape DevEdge material that they’ve brought over thus far. Woot, the core javascript docs are in there:
http://developer-test.mozilla.org/docs/JavaScript

update: Woops, I forgot to title this entry. Fixed that.

Jamil Zainasheff weighs in on AWARE regarding how he sees JavaScript and Authoware Script as co-scripting languages within Authorware playing out down the road. Here’s a hint:

If you’re new to Authorware, you’re far better off learning JS.

I’m going to avoid the obvious and not explain (for the umpteenth time) why I agree with that statement. What I will do is let out an enormous sigh of content (with that little stress symbol “‘” on the second syllable). It seems so rare that I feel genuinely excited about the future of this tool:

The result will be a modern, powerful scripting language that opens up the possibilities for authors like never before.

Considering Macromedia’s commitment to the ECMAScript standard it’s hardly surprising. Also to put his comments in context, Jamil was participating in a thread discussing the imminent release of the JavaScript for Authorware 7.02 manual from Dazzletech written by Joe Ganci. Read about the book’s current pre-order status ( including a sweet price for advance purchases) in this comment. From there you can follow the “next in topic” link to get to JZ’s post.

Another little tidbit I gleaned from that thread… Apparently Brendan Eich, who is credited with creating JavaScript, lent a bit of a hand in sorting out the implemention of JavaScript support in Authorware. That’s kind of cool.

Javascript provides a couple of operators for doing equals comparisons and it’s good to know how they differ in functionality.

The equal operator (==) is probably the more commonly used and as we all know returns true if the two values being compared are equal. When the values are of different types it converts them to an appropriate type to do the comparison.

The strict equal (===) returns true if the values are equal and of the same type.

For example:
[1] == 1; //returns true
[1] === 1; //returns false

The not equal (!=) and strict not equal (!==) operators behave similarily for unequal values. According to the Javascript docs the strict operators were added to the language in version 1.3 (current is 1.5).

This can be useful information for those of us who spend time in Authorware script and Actionscript where things are a little bit different.

Last week I needed a way to detect the presence of the Authorware Web Player version 2004 on user’s machines so I put together a javascript isAwWebPlayer2004() function to be inserted in a html page. You can download the AwWP-04_detector.js here. It contains the one function which returns ‘true’ if version 2004 of the web player is detected. I’ve tested it in Firefox 1.0 and IE 6 on a couple of windows machines. I did have offers from mac users via the aware list to give it a go but never heard back from them (hope it didn’t knock ‘em offline). So I’ve also put together a little debug page that provides a bit more detected player information rather than just true / false. That page is here if you want to try it out. If you find it’s mis-reporting please post in the comments with what it reports as well as your actual player / browser / os configuration.

Read the rest of this entry »

A few months ago I wrote a WinCtrl constructor function for Authorware 7 that makes using the winctrls.u32 from javascript more straightforward and I thought I’d share it here. Basically you create a WinCtrl object and all the properties and methods of the windows control are accessible through that object. I set it up so that any properties you’d get (or set) via the wcGetPropertyValue() of a particular control are added as property members of the object which means you can reference them like so: combobox1_wc.Visible = false; I made an effort to support all the members (properties and functions) of the winctrls and to make using the WinCtrl objects intuitive to those already familiar with working with winctrls in authorware script (aws).

Here’s some example js of setting up a listbox control:
// listbox
myLB_wc = new WinCtrl();
myLB_wc.wcDisplayControl(100, 100, 250, 200, "ListBox", "");
myLB_wc.Items = "Item 001\rItem 002\rItem 003\rItem 004";
myLB_wc._3D = false;
myLB_wc.Border = 1;
myLB_wc.Color = "#CCCCCC";
myLB_wc.FontColor = "Navy Blue";
myLB_wc.FontName = "MS Sans Serif";
myLB_wc.FontSize = 9;
myLB_wc.FontStyle = "Regular";
myLB_wc.Focus = false;

You can grab the WinCtrl.js file here. If you have any questions or comments feel free to post them here.

One thing to note, I’ve found creating a whole bunch of controls using this method is a little bit slower than other approaches. This is due to the way the properties for each WinCtrl object are being attached - the extra call to wcGetPropertiesByControl() means another trip to the u32 which seems to be the bottleneck.

This post from Vinnie at the recently rolled blog FLAmous came through the MM aggregrator this morning. He provided an actionscript version of a function to determine if a number is odd or even and described the Modulo (%) operator. I’ve pulled out the AS2 data-typing so we can use it in authorware - a week old and I’m already pilfering the man’s code.

function evenNumber(number) {
    var isPositive = ( number>=0);
    var isInteger = (number%1 == 0);
    var even = (number%2 == 0);
    return isPositive && isInteger && even;
}
aw.Trace(evenNumber(9));

The javascript object watch command now works on packaged pieces. You’ll need to package the piece with the KO that the command adds to the top of the flowline, then launch the command outside of Authorware and you’ll be able to view the js objects in your packaged piece.

Ron Lubensky has it for download over here:
http://www.clickcraft.com/aware

Here’s Ron’s earlier description of the command:

You launch the Command on your application, it pastes a KO icon into the top of it to do the work of watching your JavaScript objects. Then it resigns itself to be its non-modal interface window. So when you run your application, use the window to view the current values of your JavaScript objects, their properties and methods.

See the read-me calc as well as the help button on the command for more specific details.

peace.

From this thread on the aware list.

There is a bug in Authorware 7 where accessing the values of aws user variables in javascript (through the aw object) can return incorrect values. This only occurs in the destination file of a JumpFile() or JumpFileReturn(). According to Jamil, this is due to the fact that internal to Authorware the lookups for custom variables are referenced by index. The work around is to use Eval().

JZ also mentioned that this will be fixed in the next release (7.03, 7.5, 8.0 ??)…

peace.