Part two of the ‘Enhancing Captivate eLearning with Interactive Widgets’ eSeminar series featuring Allen Partridge and I is to be broadcast in a couple days!

If you enjoyed part 1 (and even if you didn’t) I’m sure you’ll find this one a blast as we’re going to take on that widget-of-widgets the Infosemantics Interactive Master Widget.

DUN

DUN

DAH

Oh yes, be afraid… be very af- wait. No! Don’t be afraid! I mean the Master Widget may look big and tough with its talk of slide object slavery and forcibly scoring failures along with successes, but underneath that harsh tyrantulant exterior is a widget that just wants to be loved.

…

Yeah…

Seriously, the Master Widget isn’t that hard to learn. By the end of this eSeminar you’ll be best friends and sharing beers while talking about NASCAR. I’m still blown away by what you can do with it. It’s one tool you should not be without!

Click here to register for the Master Widget eSeminar and see how your eLearning can benefit from a little slavery.

Be there or be quadrilateral!

Widget communication.

A Communication History

The first Infosemantics widget to use a form of communication was the Event Handler widget. Initially only one Event Handler widget could pick up a right mouse click at any time. So it was built in that if any Event Handler widget detected a right click, they’d notify all other Event Handler widgets.

The next widget to use communication was the Interactive Drag and Drop widget. This was the project saw the development WidgetFactory communication architecture. To date I’d say the D&D widget is still the best example of widget communication out there. In fact check out our recent eSeminar on the Interactive Drag and Drop widget, in there are a number of good examples of using multiple D&D widgets to make powerful interactions. None of that would be possible without Widget Communication.

So how does it work?

Widget Communication Explained

The Widget Communication architecture is made up of three parties.

1. The Widgets
2. The Rooms
3. The Agent

Let’s meet them.

The Widgets

Meet WidgetBill and WidgetJo

WidgetBill and WidgetJo are best friends. They like to talk very loud, which unfortunately disturbs their neighbours. So they decide to start their own exclusive club, where they, and any other like minded individuals, can ‘dude’ all they want.

First of all, they’ll need a room for their club to meet.

The Room

So Bill and Jo go ahead and design their club’s board room.

It may not come as a surprise to you that neither WidgetBill nor WidgetJo possess the craftsmanship skills to build their own room. So they search for an Agent.

The Agent

WidgetBill and WidgetJo manage to find an agent willing to take on building their room.

So the Agent goes away and does the following.

1. First of all, he checks there are no similar clubs in the district that WidgetBill and WidgetJo could join instead. If there are none, he builds their room to spec.
2. The agent inducts WidgetBill and WidgetJo into the room’s member list (which all rooms have by default).
3. He gives WidgetBill and WidgetJo directions to their new room.

And finally WidgetBill and WidgetJo have their own private room to communicate about anything they want.

The End!

Wha-?

Okay, dudeish metaphors aside, what’s really going on?

The ‘widgets’ we’re talking about are different widget instances in the exported Captivate runtime. They need to be able to communicate with each other without disturbing other widgets, so they create what’s called a Widget Room.

There are two types of rooms: Regular Rooms and Slide Rooms. Regular rooms can be joined by widgets anywhere in the Captivate Movie. Slide Rooms can be joined only by widgets on the same slide as the room’s attached to.

Now widgets can’t build the room themselves, because the two widget would end up creating two separate rooms that only they could join. So they pass the job of building the room off to the ‘agent’.

The agent takes information about the room and uses it to check if another room already exists with the same details. If there is no room, then the agent will create one. If there is a room, then it most likely exists because previously another widget asked the agent to create the room and that widget is now eagerly awaiting the arrival of the other widget. Now that the agent is in possession of a room (pre-created or otherwise) it adds the widget to the room’s member list, then passes back to the widget a reference to the room.

At the end of the day, the whole process is just a safe way of ensuring the two (or more) widgets have a reference to the same room object.

So on a conceptual level that’s how Widget Rooms work.

In the next post I’ll show you how to code your widgets in such a way as to create and join a room.

If you can’t wait till then, I suggest you check out the WidgetFactory documentation and look at the classes under the widgetfactory.communication package.

Until then, PARTY ON DUDES!

It’s that time of year again. Time to dust off the microphone and screen capture software and do some eSeminars!

The last eSeminars we did were over a year ago. Since then the Drag and Drop Interactive and Master widgets have arrived on the scene, and come on, you know they deserve some… explaining.

And we shall not disapoint!

Register now for a new series of eSeminars entitled:

Enhancing Captivate eLearning with Interactive Widgets

Up first is part 1 (though I considered starting with part 3 and working backwards like G-Lucas) all about Drag and Drop. Specifically the Interactive Drag and Drop widget (shameless link). Under its fluffy exterior, this puppy is quite powerful. The objective of this eSeminar is to get you comfortable using multiple (count them: MULTIPLE) Drag and Drop Interactive widgets together to build interactions.

Sound like your idea of fun? Then shift forward your lunch break by two hours and join us on March 14, 10 AM Eastern US time for widgety goodness!

Click here to register for this fun filled, horizon expanding, deadline delivering, buzzword abusing ESEMINAR!

May include nut.

PS: If you’re very good and come, you may get a sneak peak at the next major version of the Interactive Drag and Drop widget.

What is Runtime Detection? In short, Runtime Detection is the method for working out when the Captivate Movie is playing through the period of time the widget is set to appear in.

Now this is an interesting topic because there are many ways to do this, but finding one that is reliable AND CPU friendly AND can tell when you’ve moved out of the widget’s runtime period is difficult. In fact, one person described it as: ‘Taming an elusive wild jackalope.’

So before discussing the new Runtime Detection method, let’s take a look at a few alternative methods.

The isWidgetVisible() Method

If you cast your memory back to the days of early widget programing with the Adobe Widget Template (if anyone has memories of those days), a very important part of the widget everything was the ‘movieHandle’ object. This object has a method called isWidgetVisible(). isWidgetVisible() will tell you very reliably if your widget is being displayed in that special ‘runtime’ section. If you call it it will return true if you’re at runtime, and false if you’re not. For this to be useful, you have to set up an ENTER_FRAME event listener to check this method on each frame of the movie. This is true regardless of what slide the movie is currently playing through, of if the movie’s playing at all. In other words, this calculation is going on continually.

Now to it’s credit, it will detect runtime reliably, and it will also notice when the widget has moved out of runtime – but there’s a catch.

If you only have one widget in your movie, then this calculation isn’t much of a burden. But each time you add a new widget, an extra calculation is added. So if you have 10 widgets in the Captivate Movie, that’s 10 checks of isWidgetVisible() every frame. If the movie plays back at 30 frames a second, then that’s 300 checks a second. If you have 50 widgets in your movie then that’s 15,000 checks of isWidgetVisible() a second. After a while it starts to add up, slows down the movie. This is especially true on low end computers which may be used by a majority of the Captivate Movie’s audience.

Widgets are becoming more and more plentiful in Captivate Movies. Once upon a time, Captivate movies may only have had one or two widget in them. Now however, it’s not out of the range of possibility for one movie to have hundreds of widgets.

So let’s sum the method up:

Pros

• Reliable
• Can detect entering and exiting runtime

Cons

• The combined runtime calculations slow down the movie. So you’ve caught your jackalope, but it’s dragging its heels, and slowing you to a crawl.

From the very start, I decided this was not a viable form of runtime detection for WidgetFactory. When WidgetFactory was first released, widgets were still a new and scary feature of Captivate, and if they started to get a reputation of ‘slowing the movie down’ that could have killed them right there and then.

So I started to look for another way of detecting runtime.

The Old Method

What happens when a widget hits that special runtime period? In all honesty, not much. Widgets aren’t ‘created’ when they are displayed on the slide, they’re created right at the start of the movie. All the widget’s setup processes are handled by a different object, so it’s very difficult to find something that signals ‘runtime happening now’.

There is however, one thing that sets runtime apart from… non-runtime(?). Runtime is the only time in the Captivate movie where the widget is visible. Which means at that point Captivate must turn the widget’s visibility on.

BING! That’s different.

Now to cut a long story short, due to the ability in object oriented programming to override stuff, WidgetFactory was able to hack into the ‘visible’ switch for the widget, and call the enterRuntime() template method when the widget was turned ‘on’.

However, there was a problem with this. First of all, this only worked if the widget WAS going to be shown during this runtime period. If the visible checkbox on in the widget’s settings was turned off, then the widget wouldn’t be made visible at runtime and therefore runtime detection flat out didn’t work.

What’s more, although this method could pick up when the widget was being made visible, it did not pick up when the widget was being made invisible, because for some reason Captivate doesn’t directly turn the widget’s visibility off, but rather does so to one of its parents. So let’s break this method down again:

Pros:

• No Enter Frame loop, so doesn’t leave a CPU footprint.

Cons

• Not Reliable. The jackalope’s still prancing about free.
• Can’t detect exiting runtime.

Although this method did not tax the computer’s resources, it was a bit frustrating to work with, and under certain circumstances, such as playbar scrubbing, didn’t work at all as expected.

So it was ‘okay’ but not really ‘good’. We could do better. In fact, I had an idea for a better method, but it only became achievable after WidgetFactory 5.1.

The New Method

What if we didn’t have to rely on Captivate to tell us when the widget was in runtime? What if we could work it out for ourselves? You know, be assertive and all that. Unfortunately for a long time this was not possible because we were lacking some key pieces of information. Although it wasn’t very difficult to work out which slide the widget would appear on, it was, on the other hand, very difficult to establish which frames of the slide the widget was supposed to start and end on.

I can tell you there was much searching through Captivate’s innards to try and find a place that listed it clearly. Eventually it was discovered that widgets have XML attached to them which details on how the Captivate Author set up the widget (including when they set it to appear on the timeline ). This information was made available in WidgetFactory 5.1 through the widgetInfo property. The new runtime method takes advantage of three properties of widgetInfo: startFrame, endFrame, and isDisplayedForRestOfSlide.

Here’s the idea: WidgetFactory 5.5 widgets now have a partner in crime, the Widget Manager. The Widget Manager is like a club that every widget will join. When registering with this club, the widget provides information about itself, including the startFrame, endFrame, and isDisplayedForRestOfSlide data from widgetInfo. The Widget Manager is independent. There is only one Widget Manager in a movie no matter how many widgets there are.

Keep that in mind while I talk about something completely different. Did you know there’s a real neat method in ActionScript called addFrameScript()? It allows you to link a function to a particular frame of a MovieClip. So when the flash movie is playing that Movie Clip and it hits that frame, your function will be called.

With the information available from widgetInfo, we can now tell what frames of the slide the widget starts and ends on. So the Widget Manager uses addFrameScript() to attach a function to those frames of the slide. These force each widget on the current slide to perform a check to see whether they are in runtime.

So when the Captivate movie is playing through a slide and it hits the start frame for a widget, all the widgets on the slides check themselves to see if they’re in runtime. Those that are, call their enterRuntime() method. As the movie plays along further, it will bump into the end frame for the widget, at which point, the widgets check themselves again to see if they’ve exited runtime. If so they call the exitRuntime() method.

Now this is fine assuming that the movie will always play the frames in order (1, 2, 3, 4, 5). But in practice that doesn’t always happen. Sometimes when the Captivate movies is running low on resources it will skip a frame or two (1, 2, 4, 6, 7). If the movie skipped the start frame for a widget, then the widget wouldn’t call enterRuntime() AND THE WHOLE WORLD WOULD EXPLODE!

So to get around this inconvenient combustion, the Widget Manager (and ONLY the Widget Manager) has an ENTER_FRAME loop which continually checks if there has been a frame skip. If there has, it makes every widget on the current slide check itself to see if it has entered or exited runtime. This also clears up many of the issues encountered with the audience scrubbing the playbar. You will never get two enterRuntime() calls together without an exitRuntime() call in-between them. This allows you to load and unload the widget with the enterRuntime() and exitRuntime() methods reliably. Seeing as there is only one Widget Manager in the movie, regardless of the number of widgets, the ENTER_FRAME calculations don’t accumulate. The load remains consistent and manageable.

In other words: You can catch your Jackalope and eat it too.

Let’s review:

Pros:

• Very reliable.
• Can detect runtime exit.
• A Single Enter Frame loop that doesn’t increase the load as more widgets are added.
• Plays nice with movie scrubbing.
• Works well with widgets that are displayed for rest of project.

Cons:

• None that I’ve found so far.

Conclusion

This new Runtime Detection should give widgets a firmer ground to stand on as they continue to explore new worlds of possibilities.

Such as… Perhaps… Communication.

This static score is a bit limiting, and many people out there, who are extending the bounds of what Captivate can do, have been trying to find ways around it. Until recently the only viable method was employing Javascript. Which, for the non-programmatically minded, is – uh – Javascript.

So we wanted to find a way to open up the world of partial scoring to the grand populous. After a little more Captivate spelunking we found a way to BEND CAPTIVATE TO OUR WILL! MUAHAHA! The rest, as they say, is the Infosemantics Interactive Master Widget Version 1.1!

Don’t believe me? Take a look at this video here:

Pretty cool right?

And before you ask, yes this will be in the next version of WidgetFactory. Definitely for Interactive Widgets, most likely for Question Widgets too. WidgetFactory 5.6 shouldn’t be too far away and you can harness the awesome power of partial scoring for your very own widgets!

Bonn appetite!

(And yes I know I haven’t blogged about the features in WidgetFactory 5.5 yet. STILL GETTING AROUND TO IT!)

Here we are, two videos for the Infosemantics Interactive Master Widget (or ‘Master Widget’ for much shorter).

The first one has me, in the flesh, introducing the concepts behind the Master Widget:

The next one has me, less in the flesh, showing how to use the Master Widget to create an interaction with our Drag and Drop Interactive Widget (double publicity!).

Please leave a comment bellow if you have any questions about the Master widget.

Also I’d like to say that if you have an Interactive Widget publicly available which is not built with WidgetFactory, feel free to flick me an e-mail and I’ll let you know how to get it to work with the Master Widget.

Happy slave driving!

While I’m here I may as well talk about what I’ve learnt about question pools.

Whatfore art thou Question Pools?

From the Captivate author’s standpoint, question pools are a group that they can assign certain quiz questions to. These questions are kept separate from the rest of the lesson and left to their own devices would never appear in the movie. However, when a ‘Random Question Slide’ is added to the movie, it will pick a random question, from the pool of your choice, to display in the movie. This way the audience will get different quiz questions for each time they watch the lesson.

Here is what’s going on behind the scenes to make this happen:

When the Captivate Movie is opened all the question pool slides are created and then stored in a sort of waiting room which is separate from other slides in the movie. Random question slides however, are created and placed where the Captivate Author set them to appear in the movie. When the movie enters a random question slide, it goes searching in the waiting room for a question pool slide to display. When it finds one, the random question slide makes itself the parent of the chosen slide. So the random question slide is not replaced by the question pool slide, it becomes the parent of the question pool slide. The question pool slide is inside the random question slide. You have a slide inside a slide.

When the audience moves to the next random question slide, it will then go to the waiting room and pick its question pool slide.

So here are a few things to remember:

1. Random question slides are slides in their own right. Not just placeholders for the quiz slide.
2. The decision on which question pool slide will appear in the movie is not made until just before the audience enters it.
3. Question pool slides are not counted with the other slides in the movie. So they don’t have a slide number assigned to them.
4. Random question slides however, do have a slide number assigned to them.
5. If you had a widget on another slide of the movie which is trying to access slide elements on the question pool slide with getSlideObjectByName(), then it won’t work. Because getSlideObjectByName() will be searching for the slide elements in the random question slide, not the question pool slide.

So what does this topsy turvy system mean if you’re building a widget which might be used on a question pool slide?

Widgets and Question Pools

Perhaps the most significant difference is that the enterMovie() template method is not called at the start of the movie after the widget has set itself up. This is because the question pool slides are in the waiting room at the start of the movie and therefore outside the typical Captivate Movie structure. At this time WidgetFactory is unable to locate the elements it needs to set up the widget (like slides and the Captivate Main Timeline). So the widget delays its setup until the question pool slide is added as a child to the random question slide. The slide is now part of the typical Captivate Movie structure and the widget can find the elements it needs to set itself up, after doing that the enterMovie() Template Method will be called.

This delay in enterMovie() can cause some troubles if your widget is trying to join a widget room. I haven’t written an article on these yet, but when I do I will explain that it’s usually best behaviour for your widget to join rooms at the start of the movie. In other words: In the enterMovie() template method.

Now I’m afraid it’s not all good news and clean shoes. Although widgets now co-exist with question pools in Captivate 5 and Captivate 5.5, in Captivate 4 they are still at odds. Actually, they don’t work full stop. From the tests I’ve done, I can tell you that the movie doesn’t even get to the point of creating the widget before experiencing a terminal cardiac arrest. There is some error inside Captivate that prevents the widget being created and therefore the problem can’t be fixed in WidgetFactory. The good news is that the bug has already been fixed! So if you’re getting complaints from a user, tell them to upgrade to Captivate 5/5.5.

I hope that makes the pool a little clearer for your guys. Time to dive in!

5 POINT 5 YEEEEEHAAAA!

That’s not to say that WidgetFactory 5.1 wasn’t compatible with Captivate 5.5, but… Yeah.

WidgetFactory 5.5 has many new features, but there are three major ones. I will briefly describe them here, and then in the coming weeks write a post that goes into greater detail for each of them.

Just before I delve in here, I’d like to say that anyone out there who has an Interactive Widget should update to 5.5 as soon as possible. Why? All I can say is… Stay tuned

Debugging

Debugging has always been difficult with widgets, because the only true way to test them is to pull them in to Captivate and see how they fare. When a swf leaves the confines of its design environment a lot of its debugging features leave as well.

WidgetFactory 5.5 now has an interface to trace to external debuggers. This interface is focused on delivering the best debug experience for widgets.

If you need information on how to use these features before I write the next article, see the documentation under the WidgetDebugger class.

Communication

Widgets have come a long way since they were released, they are moving past childhood and into the awkward stages of adolescence. Probably no other milestone will be more awkward, or powerful, than communication with other widgets. But do not worry, because WidgetFactory 5.5 is here to ease the awkwardness.

Just a note up front, the communication architecture in 5.5 is not the only way that widgets can communicate with each other. In fact there are many ways that communication can be done. The hope is this architecture will help to establish a standard which will allow different types of widgets (even those created by separate developers) to communicate with each other.

Here’s the concept: There is a ‘room’ and widgets can become ‘members’ of the room. By joining the room, widgets can contact each other and make decisions that take into account all other members of the room. Alternatively, the room itself could become a middle man for its members, it receives requests from widgets and decides which should be acted upon.

WidgetFactory 5.5 provides two types of rooms:

• Global Rooms: Are available for all widgets to register with, no matter where they are in the movie. (See the BaseRoom class in the documentation)
• Slide Rooms: Are only open to widgets on a certain slide. (See the BaseSlideRoom class in the documentation)

When your widget creates a room it has to decide what type of object the room will be. A room could be created with the BaseRoom or BaseSlideRoom classes listed above, or a class of your own creation that extends either BaseRoom or BaseSlideRoom.

Anyway, more information on this to come. Until then, the third major feature is…

Runtime Detection

Runtime detection is how a widget detects the Captivate Movie is playing through the time period the widget is supposed to appear. Now this doesn’t sound like such a big deal, but believe me, it is.

The problem is not so much finding a way to detect runtime, but finding a way that doesn’t chew up CPU. It’s a balancing act of accuracy and resources, and with WidgetFactory 5.5 we’ve found that balance. I’ll tell you more about the method in another post.

When a widget ‘detects runtime’ it will call the enterRuntime() template method. We’ve all used that one right? (<– I knew this was a mistake the instant I typed it. But I kept it in and wrote this aside instead. Go figure). One thing that always bothered me about the ‘enterRuntime()’ template method was that it had no ’exitRuntime()’ method to balance it out. Well guess what… now there is!

enterRuntime() is called when the Captivate Movie enters the period of time that the widget is set to appear, and exitRuntime() is called when the movie exits that period. This will make things like loading and unloading the widget much easier. In my projects now I find myself using exitRuntime() just as much as enterRuntime().

Now there is one side effect of this new system that may cause a hiccup for certain widgets. Previously, runtime detection was tied into the widget’s visibility. However, with the new system enterRuntime() and exitRuntime() are called regardless of whether the widget is visible or not. Again, I’ll go more into this in a later post.

Everything Else

Besides those features there are a number of small additions:

Features

• Slide Label features can now be used in all versions of Captivate. However, they still can’t be used when Captivate’s accessibility features are turned off.
• New property itemName allows you to read the item name the Captivate Author gave the widget (Note: At runtime InteractiveWidgets get a suffix added to the end of their name, which leads me to…).
• New constant INTERACTIVE_WIDGET_SUFFIX holds the suffix that Captivate slaps on the end of Interactive Widget item names (The suffix is: _iWidgetAS3)
• Eliminated the need for translatePropertiesXML(). Properties are now translated the first time you access them at runtime.
• New property isCaptivate4Embedded indicates if the widget is embedded into a Captivate 4 movie (rather than being externalized).
• Added new WidgetEvent INTERACTIVE_WIDGET_SUBMITTED event which is dispatched when an InteractiveWidget sets success or failure.
• Added new WidgetEvent RESET_CRITERIA event which is dispatched when an InteractiveWidget calls resetCriteria().
• Added new property captivateMainTimeline, which is exactly the same as cpVariables, but with a more appropriate name.

Bug Fixes

• Fixed bug where Widget Properties did not appear to be saved under certain circumstances in Captivate 5.
• Fixed a bug regarding QuestionWidgets and failure levels.
• Corrected spelling mistake on WidgetInfo property maxAttempts.
• getSlideObjectByName() now takes into the account the possibility of the Interactive Widget suffix.

Known Bugs

• If a question widget is on the first slide of the movie, the enableAnswers() Template Method will be called before enterRuntime().

That’s a lot of new stuff to play around with. Have fun!

You can do all the IDE fooling you want, but like it or not, at some point you have to test your widget where it’s intended to run (in case you don’t know (and it’s a little worrying if you don’t) that’s Captivate). Which means you’ll find problems, which means you’ll code solutions, which means you’ll publish a new version of the widget, which means you’ll need to update the widget in Captivate to the current version, which means you’ll test again, which means you’ll find problems, and you’ll start the process all over again.

This, not surprisingly, takes time, and in the cutthroat world or widget building (yeah… no) we want to maximize our efficiency right?

So here’s how I go about testing my widgets.

General Testing Setup

I have a directory on my system where I keep all my widget test files. In there I have three different Captivate projects. They are:

• TestWidgetCP4
• TestWidgetCP5
• TestWidgetCP5_5

Usually I’ll do my main testing in Captivate 5 because Captivate 4 has no easy update feature, and Captivate 5.5 currently has some problems as regards updating widgets. I’ll only test in Captivate 4 or Captivate 5.5 for the sake of making sure the widget works in those versions.

Inside my TestWidgetCP5 file I have a specific structure, it goes like so:

Slide 1: Main Testing Slide

This slide holds the widget and any objects that it’s interacting with. It will be the first slide to appear in the published movie.

If I’ve got a number of widgets that I’m playing around with, I’ll create testing slides for each of them, then show and hide whichever one I’m currently working with.

Slide 2: Update Slide

This slide is hidden and contains an instance of each widget you’re testing. When you publish a new version of the widget, you’ll use the instance on this slide to update the widget.

Why? Because when you update a widget, the instance you use to update will lose its Widget Properties, while all other instances will not. If you directly updated the instance on the Main Testing Slide each time, then you’d waste a lot of time resetting its Widget Properties. However, if you update the one on this slide (which will never be seen in the movie) then you’ll save a lot of time.

Slide 3: Tracing Slide

This slide holds an instance of Whyves CPXray widget. Quite often while I’m testing one of my widgets, I’ll want to check whether a function on m_movie or a variable on the Captivate Main Timeline may hold the information I need to access. This is what Monster Debugger is perfect for. Generally this slide will be hidden. But when I want to check something, it’s simply a matter of hiding the Main Testing Slide and showing this one.

Slide 4: Rewind Slide

This slide is placed right at the end of the movie and has a single button on it. On success that button will make the movie ‘Go To Previous Slide’. This makes it quick and easy to test if your widget works when the movie has been rewound.

Testing in Captivate 4

Testing in Captivate 5 is a dream, but when it comes to Captivate 4, it becomes a lot more time consuming. As I mentioned above, Captivate 4 has no formal update function. In order to bring in a new version of your widget, you have to delete the current instance, reimport the new version, then configure your Widget Properties again. It takes FOREVER!

But there are a few cheats you can use to speed up testing in Captivate 4.

New Widget – Same Slide

If your widget accesses slide objects at runtime, then make sure when you import in a new version of the widget you bring it in to the same slide. This will save you a lot of time otherwise spent in creating the objects and naming them again (this is especially true if you follow the next step).

Bad News: If your widget is a Question Widget, then you’re sunk. Each time you re-add it to the movie, Captivate will create a new slide for it to operate on.

Set Up Default Properties

To save yourself the time and pain of having to configure properties each time you import your widget, you can hard code default properties. If you’re already using the Widget King Widget Properties Method in your widget, then you may already have default properties.

The trick is to change those default properties to the settings that you’re currently testing in your widget. That way when you import the widget into Captivate 4, all you have to do is zip over to the Widget Parameters tab, which will write the default properties, and click OK.

Publish the movie, and then if everything is set up right you should be able to test your widget instantly.

If your widget deals with slide objects, then remember you can hard code the names of the slide object into the default properties. If you’re importing the widget to the same slide, then all the slide objects will have the same name and will link up with the widget.

One Last Thing

This may seem like splitting hairs, but my preferred way of testing the widget is to hit F12 which will publish the movie and open it up in a browser. I prefer this over the traditional publish dialog because that spits up dialog after dialog while publishing the movie.

I don’t use the in-Captivate preview a whole lot, because there are subtle differences between the preview movie and the published version.

So that’s a little about my setup for testing. In a future post I will write about a number of things that are important to test before you release your widget.

Stay tuned!

With the possibility for that many slides in a single movie, managing them gets very complex. That’s why this week we’re going to look at a little object which keeps those slides in line!

Ladies and Gentlemen, meet Ms’ Movie Controller.

Meet the Control Freak

Previously we illustrated the Captivate Movie as being a family talent show. Well now let’s say that due to overwhelming critical success, the Captivate family have decided to take their show on the road!

However, it’s not as simple as doing the same song and dance routine on a giant stage in front of 6,000 people. No, no, they need to be organized about this! So the first thing they do is hire Ms’ Movie Controller to manage the acts and keep those slides in line. And no wonder, just look at her.

Would you dare cross her?

With her reputation slides obey her command without question. But what makes her fabulous at her job is not her dominating attitude, but her intimate knowledge of the show. She can tell you immediately the current slide, frame, frame rate, movie height/width, number of slides, Captivate Version… and almost any other peice of the information you could ever want.

She isn’t in charge of the movie, but she’s the go to person when you want something to happen.

Seriously, this is a gal you want on speed dial.

How to Access the Movie Controller

Every slide has a property called m_movie, which holds a reference to the Movie Controller. You may be needing the Movie Controller regularly, so it’s a good idea to save it to a variable. Here’s how you’d do that:

Here I used the widgetSlide to access the Movie Controller, but you could access it through any slide.

The Remote Control

Here are all the unique methods on the m_movie object. Many are self explanatory. Others are a bit vague. I’ve marked the ones I’ve found useful and given them a brief explanation.

• addSlide()
• clickHandlerLoaded()
• closeFLVConnections()
• Dofscommand()
• exit() – Closes down the movie.
• getCurrentFrame()
• getCurrentSlide()
• getCurrentSlideData() – This function returns a rdSlideData object that has the following properties:
  • m_playOnFrame: The number frame of the movie that the slide starts.
  • m_stopOnFrame: The number frame of the movie that the slide ends.
  • m_rdSlide_mc: A reference to the slide object.
• getFrameCount()
• getFrameRate()
• getMovieHeight()
• getMovieSlideCount()
• getMovieWidth()
• GetPlayingSlideIndex()
• getSlide()
• getSlideCount()
• getSlideIndexFromFrame() – If you pass in a number to represent a frame in the Captivate movie, it will tell you which slide is supposed to be visible for that frame.
• getSlidesInProject()
• getTOCContainerMC() – (Not in Captivate 4)
• getVersion()
• gotoFlashFrame()
• gotoFrameAndResume()
• gotoMovieSlide()
• gotoNextSlide()
• gotoPreviousSlide()
• gotoSlide()
• gotoSlideAndResume()
• hasPlaybar() – Returned false even though I had a playbar.
• isMovieReady()
• isPlaying() – Returns true if the movie is playing, false if it’s paused. Quite useful in some situations.
• isTOCVisible() – Returns true if the TOC is out, false if it’s not. (Not in Captivate 4)
• JumpToSlide()
• markSlideAsCompletedForTOC() – (Not in Captivate 4)
• movieonEnterFrame()
• mute()
• pause()
• pauseMovie()
• pauseOnInfo()
• printCurrentFrame()
• ReArrangeSlideData() – No idea what this one does, but it sounds scary.
• relayoutTOC()  – (Not in Captivate 4)
• RestoreMovieState()
• resume()
• resumeMovie()
• resumeOnInfo()
• rewindAndPause()
• rewindAndPlay()
• setMovieSize()
• SetPacemeker()
• setSize()
• showCC()
• showInfo()
• slideCompleted()
• slideLoaded()

If that’s not enough for you. Here are the object’s properties:

• m_clickHandler_mc
• m_currFrame
• m_currSlideIndex
• m_fps
• m_isPreviewForAudioDialog
• m_itemToInitialVisibilityMap – (Not in Captivate 4)
• m_keyHandler
• m_movie_mc
• m_OrigFPS
• m_paused
• m_QuizInfoLastSlidePointScored – (Not in Captivate 4)
• m_quizPlaybackController
• m_slideData_array
• m_soundHandler
• m_startPlaying
• m_state
• m_supportsSyncPlayback

Déjà vu

Some of you may find these properties and methods familiar. Yes, many of these operations or peices of information are accessible to Advanced Actions through Captivate Variables. What I believe is happening (and I can’t say for sure because I’m not a Captivate Developer) is that when you access or change one of these Captivate Variables, it diverts your request to the Movie Controller. For example, if you wanted to show the Closed Captions then usually you’d change the cpCmndCC variable like this:

But what’s actually happening behind the scenes is the Captivate Main Timeline is calling the Movie Controller’s showCC() function.

As you can see, the Movie Controller has a lot of extra gems that have not been exposed via Captivate Variables. So I suggest you pull out your nearest test widget and have a good play