Meet the Captivate Family – Slides

In the last post we learned about the Captivate Movie’s head honcho: The Captivate Main Timeline. Now it’s time to climb a little further down the family tree and meet the old man’s kids.

Ladies and Gentlemen, I give you: Slides.

What are Slides?

As users of Captivate, we think of slides as chapters in a book, each dealing with a specific topic. While that is true from a metaphorical point of view, from a technical point of view, a slide is a Display Object (Display Objects were explained in the previous post). The slide Display Object is a child to the Captivate Main Timeline.

When the Captivate Main Timeline realizes the movie needs to move to another slide, it sets that slide appear, then tells the previous slide to disappear. So the Captivate Main Timeline controls which slide will be shown next. Whereas, slides control when their objects (Such as Captions, Highlight Boxes, Images…) will appear.

I find it helpful if you can think of the Captivate Movie like this:

A Show to End All Shows!

Slides are the Captivate Main Timeline’s sons and they’re in the film business.

All of them.

And yes, in case you were wondering, they are all identical… er… Quadruplets.

What’s more, each of them are Dads too, and their kids are a real handful. Yep, they’ve got little Captions and Highlight Boxes running about at home.

The story goes that the Captivate Family are having a big reunion hosted at Grampa Timeline’s house. As part of the festivities, the grand-kids are to take part in one big talent show! However, each slide is assigned one act for all his kids to take part in. So it’s up to Daddy slide to coordinate the family act. Yes he’s the one that has to make sure little Clarance the Caption can sing her song, while Herbie the Highlight Box can dance to it.

So although the slides never appear in the act (even the slide background is a separate Display Object that the slide has hired out) they are the managing force behind it.

When one act finishes, it’s up to Old Man Timeline to decide who’s on next.

And that’s basically what the whole Captivate Movie is.

Getting a Hold of a Slide

So slides have an important place in the Captivate family. So how might we, when coding a widget, get a hold of a particular slide?

WidgetFactory has many tools for accessing slides.

The slide you’ll most commonly want to access is the slide the widget has been placed on. This can be accessed directly through the widgetSlide property.

However, if your widget is doing some behind the scenes calculations while its slide is not active, you can access the slide that is active through the currentSlide property.

But what if you just want to access the first slide, or a slide with a particular label, or you need to loop through the slides until you find a specific one, like the Quiz Results slide? In that case, you can use the getSlide() method. Just pass in the number, or label (though this will only work if the movie has Accessibility turned on), of the slide into the function, and it will return a reference to it. For Example: The next line of code will return you a reference to the first slide of the movie.

1	getSlide(1);

To store that slide reference in a variable, you’d write it like this:

1
2
3

import flash.display.MovieClip;

var firstSlide:MovieClip = getSlide(1);

So now that we know how to get a hold of our desired slide, what can we do with it?

Slide Features

Slides have a number of objects and methods that widget developers will find useful. There are a few properties…

m_paused (Boolean): Indicates whether the slide is paused or not.
m_projectSlideIndex (int): Holds the slide’s number (this value is zero based, so the first slide would be 0, the second would be 1, and so on)
m_movie: A very interesting object that is essentially a remote control for the whole movie. I’ll be writing more about this in a future post.

…But methods are really where it’s at for slides. Here are some of the handy ones:

getSlideProperties() : Returns an object that has the following properties.
- startFrame (int): The frame of the movie that this slide starts on.
- endFrame (int): The frame of the movie that this slide ends on.
- slideTyle (String): A string that describes what sort of slide this is.
- slideHandle: A proxy object of the slide.
getSlideDatabaseId() : Returns a number which… is some sort of database ID.
hasSlideAudio() : Returns a Boolean which indicates whether this slide has audio.
isSlideActive() : Returns a Boolean which indicates whether this slide is currently being viewed or not.
isSlidelet() : Returns a Boolean which indicates whether this slide is actually a slidelet.
nextSlide() : Jumps the movie to the next slide.
previousSlide() : Jumps the movie to the previous slide.
resumeSlide() : If the slide has been paused, this starts it playing again.

It’s a Slippery World Out There

Today we’ve learnt a lot about the common slide. However there are many varieties of slides, like: Quiz slides, Animation Slides, Image Slides, PowerPoint Slides, Recording Slides, and Master Slides. In the future, we may take a more in depth look at what makes these slides unique, and how you can use them to your advantage.

Widget Properties – How they’re used

Last week we looked at how Widget Properties work. This week we’ll see how to use them, and I’ll show you what Widget Properties process I use in my widgets.

How to Write Widget Properties

As we learnt last week, Widget Properties can only be created in the Properties Dialog mode, and the saveProperties() Template Method is usually the best place to do this as it is called just before Captivate requests the Widget Properties from the widget.

To create a new Widget Property, you must access the Widget Properties object (through the ‘properties’ property) and create a new property on it. I know, I know, there was an awful lot of ‘properties’ in the last sentence. It sounds complicated, and to a certain extent the concept can be, but the code is dead simple.

I’ll refer to Widget Properties as WP from now on, hopefully that will cut down the propertying

The property on the WP object will hold the data you save to it. Though initially that property will not exist on the WP object, once you create it, it will still be there when you check the WPs again.

Enough talk. Time for examples! Say the user had writen something in a text field in your interface, and you wanted to save this data to a WP called asdfasdf. Here is how you’d create that property.

1	properties.asdfasdf = textField.text;

I can assure you that asdfasdf is not an existing property on the WP object. In fact, I’d be pretty surprised if it’s an existing property on any object. However, just by assigning it a value, you create it.

Some of you may be raising your hands and asking about the good old 1119 error. You know the one you get when you misspell a property and the Flash compiler crashes the party saying:

Access of possibly undefined property asdfasdf through a reference with static type ClassName.

Well it’s true, this code usually would lead to that error. However, the WP object is special. It’s not one of those ‘static types’ it’s a ‘dynamic type’. Dynamic objects allow you to create properties on them that don’t naturally exist. Some dynamic objects you would have used before would be Arrays, Objects, and MovieClips.

There is no limit to how many properties you can create on a dynamic object. So you can create as many WPs as you like.

1
2
3
4
5
6
7
8

override protected function saveProperties():void
{
    properties.textFieldText = textField.text;
    properties.aNumberProperty = 72;
    properties.aStringProperty = "Greetings World";
    properties.aBooleanProperty = true;
    properties.anArrayProperty = [1,2,3];
}

WPs can only hold certain data types. Make sure you only save those data types to the object. If you tried saving a reference to the textField as a Widget Property instead of the textField’s text, that’s not going to work. Your whole WPs will probably fail as a result.

1
2
3
4

override protected function saveProperties():void
{
properties.myDynamicTextHoldingProperty = textField; // This won't end well
}

These are the types of data that you can save as Widget Properties.

Objects,
Strings,
Numbers,
Booleans (true and false),
Arrays, and
Null.

Also, the items inside the Arrays and Objects must not fall outside the above list.

How do I Access Widget Properties?

Once a Widget Property has been created, it can be accessed in any of the other modes that receive Widget Properties (see last week’s post)

So say we were in the enterPropertiesDialog() Template Method and wanted to set our textField back to what it was in the previous Properties Dialog session, then you’d set textField’s text equal to the WP you stored its data in, like so:

1
2
3
4

override protected function enterPropertiesDialog():void
{
textField.text = properties.textFieldText;
}

The Widget King Widget Properties Method

The problem with WPs is that they don’t come with defaults. When the Captivate Author opens up the Widget Properties interface for the first time, the WP object will be blank. In this case you need defaults set up. I like to have a variable for each of my WPs that holds its default value, then set my interface element equal to that variable. So for example, if we were using the textField example above, then the code would look like this.

1
2
3
4
5
6

private var textFieldDefaultText:String = "Default Text";

override protected function enterPropertiesDialog():void
{
textField.text = textFieldDefaultText;
}

When the Widget’s Properties Dialog opens up, the textField will be given the default text. However, before I set up the textField, I’ll insert a call to a function called checkProperties(), then go down and define that function.

1
2
3
4
5
6
7
8
9
10
11
12

There I will put in an if statement that checks if the setBefore WP equals true. If so, then I’ll set the textFieldDefaultText variable equal to the textField’s Widget Property.

1
2
3
4
5
6
7
8

private function checkProperties():void
{
    if (properties.setBefore == true) {

        textFieldDefaultText = properties.textFieldText;

    }
}

Then in my saveProperties() Template Method, I’ll extract the data from my interface and save it to WPs. Then at the end I’ll set the setBefore WP to true. So all up the code would look like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

private var textFieldDefaultText:String = "Default Text";

override protected function enterPropertiesDialog():void
{
    checkProperties();
    textField.text = textFieldDefaultText;
}

private function checkProperties():void
{
    if (properties.setBefore == true) {

        textFieldDefaultText = properties.textFieldText;

    }
}

override protected function saveProperties():void
{
    properties.textFieldText = textField.text;
    properties.setBefore = true;
}

Let’s run through the process and see how it works. The first time around, there is no setBefore property, so the if statement comes back false and the textFieldDefaultText property stays at its default value. When the properties are saved, the setBefore property is created with a true value. That means for every time afterwards the if statement returns true and the default variable’s value is swapped out with the saved property’s value. Then when that variable is applied to the interface, it’s the saved value, not the default value, which is assigned.

To add another property, create another default variable, set its associated interface element equal to that variable in enterPropertiesDialog(), associate the variable with its WP in the checkProperties() method, and save the interface element’s value to the WP in the saveProperties() Template Method.

This gives you a water tight properties system. I keep the code in the checkProperties() method separate so I can use it in other Widget Modes.

There are many different ways to handle Widget Properties. If you have your own particular method, by all means feel free to share it with us.

Widget Properties – How they work

Widget Properties! They are a wonderful thing. You could argue they are what separates Widgets from regular Animations. However, their very nature is mysterious. Where do they come from? Where do they go? When do they have lunch?

I’m not a developer of Captivate (sigh) so I can’t tell you with any absoluteness what happens to Widget Properties when they get sucked into Captivate. I can, however, tell you their life cycle as far as widgets go.

First of all though, let’s look at some basic questions.

Why do we need Widget Properties?

There are many different places that the widget swf finds itself in inside of Captivate (called Widget Modes). There is Runtime Mode, when the widget is in the published Captivate Movie and needs to be a fully functioning tool. There is Stage Mode, when the Captivate Author is editing the slide that the widget is on, and the widget needs to display a preview of what it will look like at Runtime. Then if your widget any settings, it needs to create an interface to display in the Properties Dialog’s Mode as well. A rule that Captivate follows with regards to widgets and their modes is that they never touch. You will never have the widget swf load in the Properties Dialog, then jump to the Stage preview, and then find itself being published into Runtime, or any variant thereof. What happens is the swf will load in the Properties Dialog, then reload on the Stage, and reload again at Runtime. Think of it like if you were filling out a form on the web. If you refresh the page, the form will be loaded again, and will wiped clean of anything we wrote in it. Same with widgets. When the widget swf moves from one mode to another, it will be reloaded and have no memory of what happened to it in another mode.

This leads to a major issue. How do you save any information gathered in this widget mode that might be of use in another? For example: Say we had a widget that drew a square on stage, and in the widget properties you could customise the colour of that square. If the user specifies that he wants it to be red, how do we save that information so that the other modes will know to draw a red square?

Answer: Widget Properties

What are Widget Properties?

Widget Properties are an object that Captivate holds for our widget. The widget can write information to this object (such as what colour the square should be) and Captivate will save it. When the widget swf is reloaded into a new location, Captivate will give the widget the Properties object so that it can read any information that it has set previously.

How do Widget Properties Work?

Widget Properties go through quite a life cycle. This gives me an excellent opportunity to pull out a FLOW CHART!

Lets start at the beginning.

1. Where do Widget Properties come from?

Widget Properties start their life in the Properties Dialog. The place where you should stick the settings interface for the widget.

Ah yes, but why do I keep saying that you should stick your widget’s interface here?

When the Captivate Author clicks OK the Properties Dialog will close down. Before closing down however, Captivate will request the widget give him its Widget Properties object. Sort of like if you were on a sinking ship and then these pirates came along and told you to throw your valuables at them before going down.

In WidgetFactory terms, this handing over of Widget Properties happens just after the saveProperties() Template Method is called. So saveProperties() is an excellent place to extract the information in the widget’s interface, and place them into Widget Properties, before the whole widget gets closed down.

(Yes, I built the flow chart in Captivate. I knew that software must have been good for something )

This, ladies and gentlemen, is the birth place of all Widget Properties. This is the only place where Captivate receives properties from the widget. After that it’s all give give give. You can’t change the Properties when the widget is on Stage or at Runtime. So this is the ONLY place you can allow the user the change the settings of the widget.

2. Captivate sends the Widget Properties out.

Now that we’ve saved some Widget Properties in Captivate, Captivate will send them back to the widget at the start of a new Stage Mode, Runtime Mode, or the Properties Dialog Preview in Captivate 4 (See the enterPropertiesDialogPreview() Template Method under the StaticWidget class in the documentation).

The Widget’s Properties are also sent back to the widget when it enters the Properties Dialog. Why is this? Take an example of what would happen if they weren’t given to the Properties Dialog. Say we were building that widget I mentioned above that drew a square and allowed the Captivate Author to define what colour it would be. Let’s say that the square had a default colour of blue. However, the Captivate Author enters the Properties Dialog and changes the Widget Property that controls the colour of the square from blue to red. So they close down the Properties Dialog and the Stage preview updates to show a red square. But then if the Captivate Author opens up the Properties Dialog again to change more settings, the widget will show the default settings again. In other words, the Captivate Author will open up the dialog again, see the square’s colour has been set back to the default blue, judge our widget as being buggy, and it out.

So Widget Properties are given to the Properties Dialog again, so that the widget can update its interface to hold the same values as when the Captivate Author last left it.

Let’s make what’s sending and what’s recieving clear:

Stage mode RECIEVES Widget Properties at its start.
Properties Dialog Preview RECIEVES Widget Properties at its start.
Properties Dialog RECIEVES Widget Properties at its start.
Properties Dialog SENDS Widget Properties to Captivate at its end (assuming the Captivate Author clicked OK and not Cancel)

Where’s Runtime? Well technically that should be on the list so I’ll add it.

Runtime mode RECIEVES Widget Properties at its start.

However, it’s not quite as simple as that.

3. Covert Runtime Properties

When the widget is inside Captivate, Captivate sends and recieves the Widget Properties in an Object form. For some reason I do not fully understand (again, not a Captivate Developer) at Runtime the Widget Properties object is transcribed into XML, and that’s how the Widget receives them.

SPLOT!

It requires quite a bit of time to learn the structure of the XML and how to weed your way through it to get to the properties you want. A lot of trial and erroring there. Not fun.

You can see this XML for your own if you like. It’s available under the widgetPropertiesRawData property as a String. But you need not worry about searching through an XML jungle no more.

Thankfully, WidgetFactory runs through that XML and formats it back into the classic object we are used to dealing with inside of Captivate. This saves a LOT of time and headache I can tell you. It’s probably the main reason why WidgetFactory was built in the first place.

So let’s look at the completed flow chart why don’t we?

So there you go. Everything I know about how Widget Properties work. Not a whole lot about how to use them, but next week I will be sharing the Widget Properties workflow I use in my Widgets.

See you then!

Drag and Drop Lite – Programmer Commentary

Since Captivate 4 Beta I’ve had a constant shadow. I call him Rod. I also call him Boss. I also call him Dad but that’s another story. Anyway, unlike normal shadows this one has a voice, or rather a megaphone, saying the same thing over and over again.

“Drag And Drop Question Widget…Drag And Drop Question Widget…Drag And Drop Question Widget”

(Of course I exaggerate. There are also intermittent requests that I close caption, and enhance the voice over for his course.)

And so it is today that the first commercial Drag and Drop Question Widget has been released! The product page has links to a tutorial (well soon at least) and a heap of examples (three at the moment, more to come) so I’m not going to go into that for this post. What I will do is share with you some of the history that has contributed to this widget. Although this is the first commercial Drag and Drop widget, it’s at least the fourth that I’ve built from scratch. I’ll also share with you some lessons I’ve learned in the building process.

But before you do that, I recommend you go buy the widget or look at some of the examples. You know, so that we’re all on the same page.

[Edit: There is now a trial version available on the product page for you to play around with]

A Short History of the Short History of D&D

The first Drag and Drop widget that I built was one of the examples packaged with WidgetFactory 1. It was very simple. You had a circle, a square, and a star on the left that you’d drag over to correspondingly shaped target objects on the right. In the properties you could define what combination of objects would result in a correct answer (say: Star over circle, Circle over Square, Square over star). I’m still getting e-mails from people who have customised that widget to work with their own graphics. All up about 270 lines of code.

The second was made for a course where we wanted the audience to recreate a diagram. No properties, but this widget randomised the positions of the drag objects, perfected the hit testing code when dropped on multiple targets, and amazingly came out at the same line count: 270.

Hint: Safe 7 BL, JHA TL and BR, JSA TR.

The third widget was to be used in the same course to teach Personal Protective Equipment. This one was insane.

First of all, the correct answer was to put the long brimmed hard hat on his head, along with the safety glasses. Put the boots on his feet, and the gloves on his hands, trousers on his legs. For the torso however, it’s not so clear cut. You could either put the blue and yellow high visibility shirt on, or the regular shirt with the orange high visibility vest. That’s multiple correct answers folks. That complicates the submit process (where you detect whether the question was answered correctly or not) a LOT.

Then you need to make sure that the man can’t where a hat on his foot and earmuffs on his legs. In other words, specifying which targets drag objects can be dropped on.

Then you need to have certain parts of clothing appear behind the man while others appear on top. For example when you drag the wide brimmed hat over the guy’s head, the back of the hat appears behind his head, while the shade appears over his face.

Then there’s the tool tips that come up when you leave your mouse over one of the objects long enough, the animation that plays when you clear the question, and detecting whether the target had conflicting objects (if you drag a second shirt onto the guy the old one will jump back to its starting position. But if you drop the blue safety harness on, the shirt will stay). These are all things that even the Drag and Drop Lite widget doesn’t do.

Now when I went to dig this widget out of it’s rusty subfolder, I found that I had changed a number of essential classes in my library that the widget worked off of. So it’s not working just at the moment, but I’ll (probably) fix it and post it later. Just rest assured that in its youth, it worked (almost) perfectly. Here’s a screenshot.

End line count: 704 (minus the several essential classes). By now I’ve sorta got used to programming the runtime part of the widget. It’s making it customisable with properties that’s I’m avoiding as best I can. Rightly so too. Which leads me to:

Lessons Learned

Lesson 1: The Properties Interface is Larger than the Actual Widget

The Properties Interface for the Drag and Drop Lite widget took me a looooong time to program. The Runtime part of the widget came together in a snap. Granted I’d had more practise at the runtime portion, and some of the code that controls the actual drag and dropping I’d already written for the Correct Answer tab in the Properties Interface. Let me put it another way:

The whole widget is over 4,000 lines of code. 80% of that code is for the Properties Interface. That’s with me bludging off using Keith Peters Minimal Comps component library.

You may have heard me talk about widgets as being a software program in their own right in the eSeminar a few weeks ago. Well I’d like to revise that statement: Widget’s are like two software programs. One for the Properties Interface, one for the Runtime.

Lesson 2: Captivate has White Blood Cells

White blood cells are good. They go around your body chomping down on any germs they find. Well I am now of the opinion that Captivate does indeed have an immune system. I have also come to a unique understanding of what it must be like to be a bacteria.

Just in case you ignored my advice above and haven’t seen the examples and/or bought the Drag and Drop widget yet, I’ll tell you a little bit about how it works. What you actually end up dragging around at runtime are elements on the Captivate slide, such as: Captions, Highlight boxes, Images, Animations, or anything else (except shapes). The problem is, Captivate’s not too happy about us shifting stuff about. I suppose it’s natural. I mean if you wanted to move someone’s liver to another spot in their body their immune system might have something to say about that.

WhiteBloodCells

So what’s Captivate doing? Well Adobe would have to confirm, but what seems to be happening is that when Captivate detects that one of the slide objects has had the audacity to move from its assigned location, it adds an identical object to the stage in its ‘proper’ position. Meaning that you end up seeing two instances of the same object on slide. This is REALLY ANNOYING! I found a work around that basically shifts these new objects 1000 pixels off stage so you can’t see them (hehe). It’s possible that this may be just a Question Widget thing, I don’t know. So just as a warning for anyone else tinkering with slide objects. Keep on the lookout for stray Captivate blood cells.

That’s not to discourage you from playing about with objects on the slide. As a matter of fact I encourage it! I encourage it so much that this will be the subject of next week’s post. So stay tuned.

Conclusion

It’s been a long, fun, and sometimes stressful road to building this thing. But honestly the widget’s not the most important part of the question. Like any software, the end result is determined not by how powerful the product is, but how creatively people use it. Let your imagination run wild! The types of questions you can build are unlimited.

As for me, I’m just glad to the megaphone-wielding shadow has something new to say.

“Drag And Drop Interactive Widget…Drag And Drop Interactive Widget…Drag And Drop Interactive Widget”

Top 5 of WidgetFactory 5 – #1 Custom Properties Dialog Size

When you compare widgets in Captivate 5 and widgets in Captivate 4, Captivate 5 doesn’t seem to be all that more powerful. Yes, Captivate Events do open up some interesting possibilities, but none are really earth shattering. The things that give widgets most of their power, (such as being able to access items on the Captivate Slide) are all available in Captivate 4 as well as Captivate 5.

However, if any of you reading this ever set out to make a widget in Captivate 4 that had more than a few options for the Captivate Author to specify, you would probably have found yourself bumping into an infuriatingly simple boundary.

The complexity of your widgets is set by its interface. The interface must fit in the Widget Parameter tab. The Widget Parameters tab is too small.

Seriously, take a look. A StaticWidget could be pretty much anything. But the size of its Widget Parameters tab limited them to medium complexity at best.

Interactive Widgets were better. Yet strangely, I find that most of the Interactive widgets I’ve ever built don’t have really complex interfaces.

Personally, I reckon that Question Widget’s will in general end up having more complicated properties than all other types of widgets put together. But in Captivate 4, they had the smallest properties area of all!

True, you could harness the almighty power of tabs to give yourself some room. However, you can only have so many tabs, and some tabs would end up being more densely populated than others.

On the other side of the scale, what if your widget was simple? What if all you needed for your Widget’s Properties Interface was an input text field? In that case, the interface ended up swimming in room and looked downright unprofessional.

On the humanity! What are we to do?!

Answer: Upgrade. Captivate 5 takes the one thing that was holding widgets back, and lifts it effortlessly away. Yes, widgets are now big enough to decide on their own how big they want their Properties Interface to be.

Cool, How do I do that?

Couldn’t be easier (well I suppose if the program you were using could read your mind so you didn’t have to write any code then that would be even easier than this. But I say this in a practical sense). There are two properties that handle the size of the Properties Dialog, propertiesDialogWidth and propertiesDialogHeight.

What’s that you say? You want your Properties Dialog to be 500 pixels wide by 600 pixels high? Why my good friend, just set your propertiesDialogWidth to 600, and your propertiesDialogHeight to 500. Like so:

1
2
3
4
5
6
7
8
9
10

package {
    import widgetfactory.StaticWidget;
    public class PropertiesDialogWidget extends StaticWidget
    {
        public function PropertiesDialogWidget() {
            propertiesDialogWidth = 500;
            propertiesDialogHeight = 600;
        }
    }
}

This code must go in your constructor function. By the time the widget gets to the enterPropertiesDialog() template method – it’s too late, as the size has already been set. If you publish this widget and open it up in Captivate 5, the Properties Dialog will look like this (minus the outspoken comment of course).

That’s pretty much it. I have now run out of practical things to tell you.

OH! If you want to optimise your code by one line, and make it look like you understand how Object Oriented Programming works, you can get the same result as above by writing this instead.

1
2
3
4
5
6
7
8
9
10
11

package {
    import widgetfactory.StaticWidget;
    public class PropertiesDialogWidget extends StaticWidget
    {
        public function PropertiesDialogWidget() {

            //super(Properties dialog width , Properties dialog height);
            super(500,600);
        }
    }
}

This does exactly the same thing, the first parameter takes the width, and the second the height. It’s no more or less powerful, it just looks cooler. Technically what’s going on here is that we’re sending our desired width and height for the Properties Dialog into the constructor function for the StaticWidget class (That be the class we’re extending. Known as the Super Class).

Anything else?

Well… here are a couple of tips for you:

The Properties Dialog width and height will default to (almost) the same size as it was for that type of widget in Captivate 4.
If you specify a Properties Dialog size that is different to the stage size of your flash file, then be warned, the widget WILL be resized. Now there is more than one way to resize a swf. WidgetFactory sets the resize mode for the stage to NO_SCALE. Which means that when we make the window larger we will see more of the stage, and when we make the window smaller we’ll see less of it. Outside of WidgetFactory, the typical method of resizing the stage would stretch it to the new size, but this results in the contents of the swf being distorted. For more information on stage scale stuff, see the ActionScript Live docs.
If your widget doesn’t need a Properties Interface, you can make impossible for the Captivate Author to open the Properties Dialog by setting its width and height to 0, or by calling disablePropertiesDialog() in your constructor function. Note: This will not stop the Widget Parameters tab from appearing in Captivate 4.

End of an Error

Well that’s the top 5 features in this release of WidgetFactory. You now have some serious weapons at your disposal for your next widget. But wait! There’s more! Starting from next week I’ll be blogging about… Something else. Haven’t quite decided what yet as there are so many things to blog about. So I thought rather than being selfish and writing about whatever I want, I’d let you guys decide.

Loading ...

Got something pretty specific you’d like to learn? Perhaps some feature of widgets that is making itself hard to grasp? Let me know and I’ll see what I can do (that is of course if I’m not totally flummoxed by it too. Which is more than likely).

Happy Widget(t)ing!

The Widget King