View Full Version : Udating Grid from Editable to simple grid and vice versa on the fly

12 Jul 2010, 8:25 AM
Hi There,
I created Editable Grid in Designer. Now a situation came where I have to replicate same grid for 2 different purpose.
So instead of replicating the same grid can I transform editor grid to normal grid. Or Can I disable the column editing facility on the fly.
If this can be done then I dont have to create 2 windows for almost the same functionality. I tried disabling but it disabled everything including scroll bar so this is not what I desire.
Please guide me to this

12 Jul 2010, 10:04 AM
Hi sajan,

You can Right-click->Duplicate your EditorGridPanel, and then transform it into a regular GridPanel. The column editors will automatically be removed by the transformation process.

Does that help?

12 Jul 2010, 3:00 PM
Thanks Jarred,
Yes I know how to do that but it is not what I want. Instead of creating 2 grid I wan to use the same grid. When Clicked from "A" button it should be editable but when clicked from "B" button it shouldn't.
Can that be done?
ps: there are 9 columns in that grid with around 300 rows (pagination not required, so had to show everything at once). but when i try to resize the grid in browser,it stucks for some seconds. why is that happening and how to remove that?

13 Jul 2010, 6:25 AM
Hi sajan,

I'm sorry, I misunderstood your question.

You can accomplish this in one of two ways:

You can enumerate through the Column Model (e.g, myGrid.colModel.columns) and set each column's "editable" property to false (e.g., myGrid.colModel.columns[0].editable = false;) to disable editing, and then set them all to true (e.g., myGrid.colModel.columns[0].editable = true;) to enable editing.
You can detach the "celldblclick" event handler from the grid, to disable editing (e.g., myGrid.un('celldblclick', myGrid.onCellDblClick, myGrid);). When you want to reinstate editing, you can reattach the event handler (e.g., myGrid.on('celldblclick', myGrid.onCellDblClick, myGrid);).

Hope that helps!

13 Jul 2010, 6:42 AM
wow wow wow
Thanks Jarred,
yes your both technique worked.

I used your first technique to disable cell edit &
used second technique to prevent re-saving of data again and again (I used row deselect event to save data back to 4D Database).

But one question still remains ;)
After Grid is rendered. If I re size the Ext Window (which contains the Grid) it takes some time to refresh. So Please guide me on that too

13 Jul 2010, 6:55 AM
No problem :-)

Does your grid contain a lot of data? Sometimes a grid with a lot of data and/or a lot of columns will take some time to repaint itself. There is a buffer of either 50 or 100 milliseconds during a window resize event before all child components are laid out again, so that it basically waits to render once the resize action is over. A "buffered event" is canceled if it is fired a second time within the buffer timeout, and we use that technique during a resize to prevent too many unnecessary repaints. So that means it is guaranteed that you will wait at least 100 milliseconds before the grid will be repainted after a window is resized. Other than that, it could be that the grid is large.

With that said, we are always working to improve the rendering time of our components, particularly the GridPanel. If you are simply displaying data, I would recommend the ListView as it is a much lighter-weight component. You will see GridPanel render improvements in future Ext JS releases.

13 Jul 2010, 7:00 AM
Thank for the Quickest response
Yes My grid has 9 columns and minimum 100 rows . Pagination is not "the client's need" so SO I have to show all the data at once. The grid can have at most 1200 rows (worst case scenario). So is it the data that is causing the problem. If yes please let me know so that I can persuade client to implement pagination ;)

13 Jul 2010, 7:19 AM
It is a combination of 9 columns and 100+ records. I can confidently say that pagination is recommended and would solve the issue. Between 25 and 50 records per page would show an improvement in speed, definitely. You can start out with 100 and work your way down in size until you find acceptable performance.

1200 records with 9 columns will be very slow, so I'd definitely push the client and recommend pagination.