Hi Pan,
I completely agree with you ... the progress bar definitely seems designed
around the conventional use case you described of being hooked to a Loader
(or derivative). For something so simple it should have been generalized a
bit more.
I think Alex's point was that yes, it's a bug, and a workaround would be
using an EventListener object for the source... of course, you could always
sub-class or cut-n-paste the ProgressBar to make your own that does the
right thing... until Adobe provides a bug-fixed version, that is.
Beyond that, let's hope that the bug gets fixed properly, the API gets
tweaked appropriately, and we get a new SDK drop in the future! ;-)
Troy.
On 5/2/07, Pan Troglodytes <[EMAIL PROTECTED]> wrote:
Oh, I definitely could, if I absolutely had to make it work this way.
The problem I see is that the polled mode is very useful for a very specific
set of circumstances. But I don't find it very useful in the general
sense. It's called a "progress bar", but it seems to have been designed
very narrowly (at least in polled mode) as a bar to hook up to different
loaders of content, measured in bytes. A polled method would be very useful
and easy to use, if it just had an event defined for the progress bar for
getTotal and getProgress. Then it would be a breeze to hook up the events
and be on your way.
The help is also erroneous in claiming it uses "getBytesLoaded() and
getBytesTotal() methods." In the code, it actually reads "bytesLoaded" and
"bytesTotal" properties. This also thwarts my plans of just having a simple
object like this:
[Bindable] public var progress:Object = {
bytesLoaded:getProgressBytesLoaded,
bytesTotal:getProgressBytesTotal,
removeEventListener:kludgeRemoveEventListener
}
private function kludgeRemoveEventListener(event_type:String,
listener_function:Function):void { }
private function getProgressBytesLoaded():Number
{
//figure out current progress...
return currentProgress;
}
private function getProgressBytesTotal():Number
{
return maxProgress;
}
On 5/2/07, Alex Harui <[EMAIL PROTECTED]> wrote:
>
> Looks like a bug. We expected the source to be an EventDispatcher.
> Can you subclass EventDispatcher instead of Object?
>
>
> ------------------------------
>
> *From:* [email protected] [mailto: [EMAIL PROTECTED]
> *On Behalf Of *Pan Troglodytes
> *Sent:* Tuesday, May 01, 2007 9:31 PM
> *To:* flexcoders
> *Subject:* [flexcoders] ProgressBar.mode="polled" gives me problems
>
>
>
> All the help says about setting ProgressBar.mode="polled" is:
>
>
> polled: The source property must specify an object that exposes
> getBytesLoaded() and getBytesTotal() methods. The ProgressBar control calls
> these methods to update its status.
>
> But this doesn't seem to be true. For example, it seems
> ProgressBar.commit always wants to do this to the source:
> _source.removeEventListener(ProgressEvent.PROGRESS,
> progressHandler);
> _source.removeEventListener(Event.COMPLETE,
> completeHandler);
>
> Which is a real drag if your source was going to be a simple little
> object with just getBytesLoaded() and getBytesTotal() methods.
>
> It's a bit silly that the code always tries to remove these event
> listeners whenever you set the source, since these event listeners never got
> set to begin with (the source was empty before setting it).
>
> Is there something I'm missing or is the mode="polled" setting a bit
> funky? My searches seem to show very little information for people using it
> this way.
>
> --
> Jason
>
>
--
Jason
