As promised, you can now watch part 2 of the tutorial for loading objects from the Captivate library into your widgets.
If you missed part 1, you can see it here.
This part of the tutorial deals with the External and Embedded Resource Lists, and how to load library objects into other widget modes.
Edit: See part 2 here.
I have finally made a tutorial on loading stuff from the Captivate Library! This is by far the most exciting new feature in Captivate 6 as far as widgets are concerned. Unfortunately in all the time since CP6 was released, I haven’t put up a tutorial on how to do it. So finally the silence is broken! And it is broken in video! Which is a good thing, because technically a blog post is not an audible format, thereby silence would not have been broken that way.
mzmnt~
N-E-WAY, here’s the tutorial.
Hopefully I’ll have part 2 up soon where I explain how you can register which library objects you want to access at runtime.
Till then, happy loading from the library!
I get asked this question a lot, so I thought I’d make a video on it.
How to Access Captivate Variables in CP6 if you’re using the Adobe Widget Template.
If you’re using an animation or for some reason do not have access to cpSetValue, then don’t worry, everything’s not lost. The getMovieProps() function is available two parents up from the animation’s main timeline. So just use this code:
1 |
In the last post we looked at how to form the foundation for a widget. In this post we will see how to set the widget’s type.
If you are using the ‘old’ method of building widgets, you’d specify your widget’s type by which class you extend. If you wanted to build a static widget you’d extend the StaticWidget class, if you wanted to build an interactive widget you’d extend the InteractiveWidget class and so on.
With the new Widget method in WidgetFactory 6 (I’ve really got to come up with a better name for that) no matter what type of widget we’re building, we always extend the Widget class, which is type independent. By default, the Widget class will be a static widget, so how do we tell WidgetFactory that we want to build an interactive or question widget?
At the end of the last post, our widget was looking like this:
1 2 3 4 5 6 7 8 9 | package { import widgetfactory.Widget; public class MyWidget extends Widget { } } |
This bare bones widget will import into Captivate as a static widget. To make this an interactive widget, first of all we must build a constructor function. When the MyWidget class creates a MyWidget object, its constructor function will run immediately. We identify the constructor function by giving it the exact same name as the class. So let’s add a MyWidget function to the MyWidget class.
1 2 3 4 5 6 7 8 9 10 11 12 13 | package { import widgetfactory.Widget; public class MyWidget extends Widget { public function MyWidget():void { } } } |
The Widget class has its own constructor function as well, and its constructor function is set up to receive two pieces of information. The first piece of information is what type of widget this is going to be. The second piece of information is a bit complicated and outside of the scope of this post (though we’ll get to it some day). To send this information to the Widget class’ constructor function we use the ‘super()’ method. Super is short for ‘super class’ which means the class were extending, which of course in this situation is the Widget class.
A few posts ago I showed how to use the WidgetType class to detect what type of widget you’re in. The WidgetType class also has another use. If you recall the widget class has three static properties:
These represent the static, interactive, and question widgets. When we call the ‘super()’ function we can pass in one of these properties and that will specify what type of widget we’re building.
Of course, you must import the WidgetType class before you can access it. The WidgetType class is located under the widgetfactory package, so just add…
1 | import widgetfactory.WidgetType; |
…to your class and you’re set.
So in the end, an Interactive widget would look like this:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | package { import widgetfactory.Widget; import widgetfactory.WidgetType; public class MyWidget extends Widget { public function MyWidget():void { super(WidgetType.INTERACTIVE); } } } |
And a question widget would look like this:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | package { import widgetfactory.Widget; import widgetfactory.WidgetType; public class MyWidget extends Widget { public function MyWidget():void { super(WidgetType.QUESTION); } } } |
There is another way to define your widget type that does not involve this ‘super()’ call, but I’ll explain that in another post. For our next post, we’ll learn about widget modes!
From the dark widget ages it was theorised; in the widget revolution it was proved possible; but now moving into the next widget era, it is practical. What am I talking about?
Widget communication.
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?
The Widget Communication architecture is made up of three parties.
Let’s meet them.
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.
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.
WidgetBill and WidgetJo manage to find an agent willing to take on building their room.
So the Agent goes away and does the following.
And finally WidgetBill and WidgetJo have their own private room to communicate about anything they want.
The End!
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!