What would really be cool would be for ProgressBar to explose a property for
the progress value. It's very close to doing this. I made the following
subclass that works for me for now:
package nes
{
import mx.controls.ProgressBar;
import mx.core.UIComponent;
public class ProgressBarExt extends ProgressBar
{
public function set value(newValue:Number):void
{
setProgress(newValue, maximum);
}
}
}
Then I have the following in the XML:
<nes:ProgressBarExt
id="startupProgress"
height="16"
labelPlacement="center"
indeterminate="false"
width="240"
mode="manual"
value="{main.progress}"
complete="loadComplete()"
/>
This reads the "[Bindable] public var progress:Number;" variable of the "
main" object. The downside is that I have to initialize maximum in the code
because of the way the underlying ProgressBar code works. If you don't do
this, it clears the maximum set in the XML when it initializes mode="manual"
.
On 5/2/07, Troy Gilbert <[EMAIL PROTECTED]> wrote:
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:* flexcoders@yahoogroups.com [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
>
>
--
Jason
