I had an e-mail yesterday regarding some specific AS3 question on how to lock the playbar’s progress bar. Micheal already created such a widget in AS2 and made it available on his blog. However, he didn’t find the time yet to create an AS3 version. So, with that in mind, I decided to take a look at it and investigated the issue. I will post the new AS3 Playbar Lock Widget in a subsequent post as I’m not totally finished with it yet.

To create the widget, I chose to give a dry run to the static widget class in CpGears. In essence, I was eating my own dog food. Turns out that some chunks were really sweet while others left a bitter taste in my mouth. Fortunately, the bitterness will be very easy to correct and I’m already adding some sweeteners.

One of the new feature of CpGears is the handling of the life cycle of the different widget views (Runtime, Edit, Stage and Preview). I think that it will be a very much appreciated feature but it does require a little bit of fine tuning. On the other hand, one of the sweet spot was using the integrated logger. That did help me a lot!  So,  stay tune for the official release of CpGears but it will take more time as it’s a lot of work!

I saw today a very interesting comment in my previous post about widget events. I was basically complaining (I know … I need to stop doing this ) about the Slide eventing system to be a little bit flaky. Shameer (Senior Product manager at Adobe) was very helpful (as usual) and got one of the Adobe software developer to take a look at my comments. It ended up that the developer did explain the behavior but I was not really happy with the explanations since I still see the eventing system as flaky. I also mentioned … again … that the API could see some improvements and I asked Shameer if they would be working on the API for Cp6. Turns out that they will and they will also listen to me and other widget developers in the community. That’s great news!

In order to keep my comments in one place, I have created a new page just for that purpose. I will start putting more comments there as I hit problems and frustrations with my CpGears API. You are welcome to contribute through the comments and I will move the data to the main page as I read them. By the way, I have just installed a new plugin that will allow you to follow the comments in the post. Just make sure you check the ”Notify me of followup comments“ checkbox below the comment box.

When Captivate 5 came out, one of the  interesting feature that was added to the widget API was the EventDispatcher and the different movie events. Before this feature, the developer had to hook himself on the ENTER_FRAME event and check, on each frame, the value of different captivate variables in order to determine the current slide, the current frame or the movie status. This seemed to be a very promising feature long awaited by widget developers.

Unfortunately, tapping into it is not as simple as it seems. First hurdle:  the Captivate Helpdoesn’t mention this EventDispatcher at all. However, sometimes if you dig and are patient enough, you can find gems … and the Captivate 5 installation folder has a few nice ones. Hidden in the ActionScript folders are the different classes that can be accessed by the widget at runtime. If you are familiar with the lifecycle of a widget, you know that at runtime, a movie handle is passed to the widget via the cpSetValue() function. For those of you that aren’t, consider reading this.

So, at runtime, the Captivate player passes the movie handle to the widget. From there, you can call the getMovieProps() function to retrieve a reference to the CPMovieProperties instance. This class instance contains a property that is not mentioned in the help and that is named: eventDispatcher. This property will return an instance of an IEventDispatcher which will allow you to monitor the following Captivate events:

• CPSlideEnterEvent (Entering a slide)
• CPSlideExitEvent (Exiting a slide)
• CPMovieStartEvent (Starting the movie)
• CPMovieStopEvent(Stoping the movie)
• CPMoviePauseEvent (Pausing the movie)
• CPMovieResumeEvent (Resuming the movie)

You would think that the problems stop here and that the widget can now live happily ever after. Hum … sorry to disappoint you but the eventing system is a bit flaky. Here are my observations:

• The first time the EnterSlide event is fired on the first slide, the movie is on frame #2. If you rewind the movie, the EnterSlide event is now fired on frame #3. So, why frame #2 initially and frame #3 ever after?
• There is a lost frame between the ExitSlide event and the next EnterSlide event. For example, Side 2 fires up an ExitEvent on say frame 181. The movie keeps playing and the next EnterSlide event is firex on frame … #183. What happened to frame #182? Granted it’s not that important but it’s bizarre none the less.
• When the movie stops on the last slide (say 4) and on the last frame (say 285), if the movie is rewound, an ExitSlide event is thrown originating from Slide 4 (fine) but for frame … #1! That is impossible, you expect it to be Slide 4 – Frame 285. Looks like a bug to me.
• There is a very strange behavior when dragging the thumb of the progress bar in the playbar. If you start the movie and pause it after a few seconds but before the first slide ends, you can scrub the thumb back and forth without any problem. That is as long as you scrub within the first slide. If the thumb crosses over to slide #2, an ExitEvent for slide 1 and an EnterEvent for slide 2 are thrown. That is perfectly normal. What is not is when you scrub back the thumb into slide 1, then you get an EnterSlide event for each frame of slide #1. This is very annoying! If you want to check that up for yourselft, just let the movie play to the end and then click on the thumb and scrub back. If your movie has 200 frames, you’ll get 200 EnterEvents. Again sounds like a bug to me!
• When you click on the thumb of the progress bar you get inconsistent events such as pausing, resuming, exiting a slide, etc. I was not able to get a reproducable pattern. However, one thing I can reproduce is if I scrub the thumb all the way back to the beginning of the movie, I then always get a Resume event  followed by an Enter event.

This inconsistent behavior makes this feature hard to use in real life without resorting to hacks. If you plan to use Captivate Events, just be on the look out for unwanted side effects. Now, I will need to report these problems to the Captivate team … unless one of the Captivate  developer happens to read this blog

I have been very quiet for the last few weeks. So, I decided to break radio silence and let you in on what I’m actually working on. I’m currently working on creating my own Captivate Widget API that will be called CpGears. As you read this, I’m sure that one question will come to mind: “Why are you doing this? Tristan already created his very good WidgetFactory API”  Well, that’s true; Tristan did an amazing job with his API but I want to do mine for specific reasons:

• Personal challenge and accomplishment
• Tristan wants his API to be accessible to developers of every caliber while I want mine targetted to more advanced users.
• Having more than one option is always a good thing. Just take  a look at all the similar AS3 libraries out there.

I’m almost done with the Static widget and I will soon start working on the other two types: Interactive and Question. Some of the things that I’m adding with my API are:

• A logger interface so you can log and trace messages from your widgets.
• A different way for handling the widget flow/lifecycle.
• A more object oriented approach to accessing the widget data. I don’t like the CpMovieHandle, CpSlideHandle, CpSlideProperties and other native widget classes. So, I offer a more structured interface for accessing that data.

The API will be developed under a MIT Open Source License and be hosted on Google Code. In order to make sure that I don’t directly compete with Tristan and his API, I will make mine only Cp5 compatible so people that want to develop widgets for both the Cp4 and Cp5 plateforms will still have to rely on Widget Factory. By the way, Tristan is aware of this and we have discussed that a few months ago.

So, come back and visit us in 2 or 3 weeks.  I’m actually advancing at a turtle pace since I don’t have that much free time on my hands.