ruby-****@sourc*****
ruby-****@sourc*****
2009年 2月 16日 (月) 01:59:05 JST
-------------------------
REMOTE_ADDR = 74.15.84.244
REMOTE_HOST =
URL = http://ruby-gnome2.sourceforge.jp/hiki.cgi?tut-gtk2-treev-addrnhs
-------------------------
@@ -365,7 +365,7 @@
=== Removing Multiple Rows
-In this part of our application we find two remove methods. The main is the callback method called ((*remove_products*)). Though most of the actual removal processing is done by the helper method ((*remove_row*)), there are some important removal issues that need to be addressed when dealing with removing multiple rows, in the first, that is, "remove_products" method. Let us first look at the helper method, which is designed to remove a single row.
+In this part of our application we find two remove methods. The main is the callback method called ((*remove_products.*)) Though most of the actual removal processing is done by the helper method ((*remove_row,*)) there are some important removal issues that need to be addressed when dealing with removing multiple rows, in the first, that is, "remove_products" method. Let us first look at the helper method, which is designed to remove a single row.
:remove_row(ref, model):
The first thing to notice about this method is that it receives a reference rather than an iterator or a path to the row in the tree store, which will be removed. It then uses this reference to convert it to the iterator as well as path, first to adjust the value of the quantity total in the parent for the value that will be removed from the selected child row. Finally, the path to the child row is converted to iterator with which the row is removed from the tree store. All these conversions from reference to iterator and path look rather convoluted, however there is a good reason for all this. Namely, passing around ephemeral iterators and "hard-coded" or "burned-in" paths could potentially spell a disaster while inserting and/or removing rows on a massive scale.