I’m taking a break from Captivate family relations for a moment (they’re so sensitive!) to touch on a rather essential topic.
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:
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.