Hmmm, thanks for the reality check. I refreshed myself on the
ListCollectionVIew source, remembered the dispatch boolean being passed in
as false in reset but must have overlooked the dispatchResetEvent bit.

In reading I did notice this bit:
            if (sort)
            {
                sort.sort(localIndex);
                dispatch = true;
            }

And after a quick test looks like I don't even need to be calling refresh
when there's a sort applied as the internalRefresh function is handling it.
Any quick tips on when refresh() actually needs to be called? Definitely
don't want to be forcing controls to run their update code twice...

On Thu, Jul 31, 2008 at 7:14 PM, Alex Harui <[EMAIL PROTECTED]> wrote:

>    Should dispatch COLLECTION_CHANGE with RESET.
>
>
>  ------------------------------
>
> *From:* flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] *On
> Behalf Of *Daniel Gold
> *Sent:* Thursday, July 31, 2008 5:10 PM
>
> *To:* flexcoders@yahoogroups.com
> *Subject:* Re: [flexcoders] How to temporarily stop a dataProvider from
> updating UI
>
>
>
> really? I thought controls like DataGrid listened for CollectionChange and
> thought swapping source only did an internal refresh without firing a
> COLLECTION_CHANGE. I do use Sorts and filterFunctions pretty often so maybe
> I'm way off base...
>
> And I tried to note that the loop was unneccessary, but most of the time
> there is some kind of processing or merging going on with the new source
> instead of just taking the array handed back.
>
> On Thu, Jul 31, 2008 at 7:06 PM, Alex Harui <[EMAIL PROTECTED]> wrote:
>
> Yeah, that's basically it.  If you have an IList you can just call
> toArray() and concat it to any existing array of data.  You shouldn't have
> to call refresh unless there is a sort or filter applied.
>
>
>  ------------------------------
>
> *From:* flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] *On
> Behalf Of *Daniel Gold
> *Sent:* Thursday, July 31, 2008 5:02 PM
> *To:* flexcoders@yahoogroups.com
> *Subject:* Re: [flexcoders] How to temporarily stop a dataProvider from
> updating UI
>
>
>
> I've seen a lot of posts with performance related to using Bindable
> Collections like that. One of the dangerous of having such a useful easy API
> for updating controls...
>
> Just to expand on what Alex is suggesting, suppose your service call
> returns to a function called updateData, and your control is bound to a
> _data ArrayCollection
>
> public function updateData(newData:IList):void
> {
>      var newData:Array =[];
>      for each(var data:Object in IList)
>      {
>           _newData.push(data);
>      }
>      _data.source = newData;
>      _data.refresh();
> }
>
> That's an extremely basic code example, and actually unnecessary to loop
> like that in most cases, but basic principle is get your data structured in
> an Array or similar structure, add new items, remove old unnecessary items,
> whatever you need to do, concat or replace the source Array of your
> ArrayCollection, and then call refresh which will dispatch a
> COLLECTION_CHANGE event which will trigger any controls using it as a
> dataProvider to update.
>
> On Thu, Jul 31, 2008 at 6:47 PM, Alex Harui <[EMAIL PROTECTED]> wrote:
>
> There is enable/disableAutoUpdate, but adding rows one at a time is
> inefficient.  Just concat the two arrays and replace the dataprovider
>
>
>  ------------------------------
>
> *From:* flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] *On
> Behalf Of *whatabrain
> *Sent:* Thursday, July 31, 2008 3:23 PM
> *To:* flexcoders@yahoogroups.com
> *Subject:* [flexcoders] How to temporarily stop a dataProvider from
> updating UI
>
>
>
> I've found that adding a lot of rows (1000+) to an AdvancedDataGrid can
> be quite slow, if the rows happen to be visible (in an open node of the
> tree). I don't know why this is the case, especially since it's not the
> case in a regular DataGrid, but I'd like to work around it.
>
> So how can I tell the AdvancedDataGrid to temporarily ignore updates to
> the dataProvider? Once the large number of rows have been added, I'll
> turn the automatic updating back on, for the slow trickle of updates
> that come after that.
>
>
>
>
>
>  
>

Reply via email to