3.6 is due out soon.  It is fixed in that code base.  I think there may be 
nightly build on the 3.x branch.


On 7/28/10 9:23 AM, "Richard Rodseth" <rrods...@gmail.com> wrote:






True - it's given me many headaches.

Any ideas for a workaround? A judiciously-placed callLater ? Some combination 
of invalidateXX ?
Even something like this doesn't work:

                    var source:Array = conditions.source;
                    conditions.source = [];
                    conditions.source = source;
                    conditionList.invalidateList();


On Tue, Jul 27, 2010 at 10:12 PM, Alex Harui <aha...@adobe.com> wrote:





Flex 3.5 has some issues with ComboBox updating.



On 7/27/10 4:22 PM, "Richard Rodseth" <rrods...@gmail.com 
<http://rrods...@gmail.com> > wrote:






I have two scenarios where I have to refresh rows of a list or
datagrid because the contents are computed, and one of the inputs  to
the computation (some meta-information) has changed.

In the first (a DataGrid) I just have a labelFunction for one of the
columns, and calling refresh() on the ArrayCollection in the
presentation model does the trick.

The second is more complicated - the list has an inline item renderer
which is really a mini-editor containing a combo box. I'm struggling
to get the combobox label to update. Tried calling refresh() on the
array collection, invalidateList() on the list, and even
executeBindings() on the list, to no avail. Binding works in all other
use cases, eg. inserting and deleting items from the list.

Any special considerations with an inline item renderer or combobox
when forcing a refresh?

As an aside, this description from the LiveDocs for executeBindings is
a bit odd.

>>
Executes the data bindings into this UIComponent object. Workaround
for MXML container/bindings problem (177074): override
Container.executeBindings() to prefer descriptor.document over
parentDocument in the call to BindingManager.executeBindings(). This
should always provide the correct behavior for instances created by
descriptor, and will provide the original behavior for
procedurally-created instances. (The bug may or may not appear in the
latter case.) A more complete fix, guaranteeing correct behavior in
both non-DI and reparented-component scenarios, is anticipated for
updater 1.
<<





--
Alex Harui
Flex SDK Team
Adobe System, Inc.
http://blogs.adobe.com/aharui

Reply via email to