views:

628

answers:

3

For poor performance reasons, the DataGrid will cache checkboxes and reuse them for different rows. If you have 50 rows, it won't create 50 checkboxes. It will create as many checkboxes at are visible, plus a few more for padding, and then reuse them as you scroll. This is why you need to explicitly manage their state. How can improve it ? How can fixed checkbox value ? i used checkbox like below But checkbox doesnot remembering the values

 <mx:DataGrid id="calamount"dataProvider="{xml_coupon.lastResult.Teamcoupon.match_details}" variableRowHeight="true">
<mx:columns>
    <mx:DataGridColumn headerText="1"  rendererIsEditor="true" editorDataField="selected">
    <mx:itemRenderer>
    <mx:Component>
    <mx:HBox verticalAlign="middle" paddingLeft="2">
    <mx:CheckBox  id="checkbox1"  selected="{outerDocument.checkedAll}" click="{data.check1=checkbox1.selected;outerDocument.calcValues()}"/>
    </mx:HBox>
    </mx:Component>
    </mx:itemRenderer>
    </mx:DataGridColumn>
</mx:columns>

A: 

I'm not sure I fully understand your question, but if you're looking for ways to improve the performance of your custom item renderers I would start by reading the excellent post by Alex Harui on his blog. Specifically, the section on performance:

Performance

When designing custom item renderers, you should keep performance in mind. While it is simple and fast to take a Canvas, HBox or VBox and put a few components in there and have a renderer, keep in mind that containers are really big and slow and if you are going to have lots of them visible in your DataGrid, you might run into performance problems. We often don't see them because we develop on really fast machines, but you have to consider what kind of hardware your end-user will have. So, I'd discourage the use of any container from mx.containers in a custom item renderer if there's going to be more than a half-dozen on screen. Unless you are laying out more than three or four widgets in your renderer, it will be much faster to start with UIComponent and just write some logic to layout the components in their correct positions. Containers from mx.containers also factor in deferred instantiation logic, scrollbars, clipping and a bunch of other things that your probably don't need to use in your renderer.

That's why you'll see that all of the examples use ActionScript instead of MXML. Yes, that means that you can't use FlexBuilder to code the renderer, and yes, some of these examples could be done in MXML, but it is easy in MXML to do things that generate extra code that you may not need. You'll notice that I do not use databinding in these examples for the same reason. It is actually a bit wasteful (although very convenient) to use binding on something that isn't going to change or only change once or twice. Instead, I set the dataprovider on the initialize event (and would do so on a result event if I used HTTPService).(1)

Dan
A: 

Do you mean that your checkboxes aren't remembering the values? You have to make sure you make your item renderers data driven.

<mx:CheckBox selected="{data.someBooleanProperty}"/>

That way when you scroll around, it will make sure they are checked/unchecked correctly.

Sean Clark Hess
i try that <mx:CheckBox selected="{data.someBooleanProperty}"/>but stil checkboxes does not remembering the values ? if i scorlling scrollbar in datagrid then checkbox selected also checked
R.Vijayakumar
you need to replace "someBooleanProperty" with a property on the dataprovider
Sean Clark Hess
A: 

You're binding the check box selected property to the wrong thing. It should be bound to data.check1 (nice suggestive name) judging by the code in your click event handler. Which, by the way, should have been "change" event, because you can change the value of a checkbox when you press ENTER or SPACEBAR and it has the focus, and you won't get a click event in that case.

bug-a-lot