ruby-****@sourc*****
ruby-****@sourc*****
2012年 8月 25日 (土) 03:25:52 JST
-------------------------
REMOTE_ADDR = 70.49.49.99
REMOTE_HOST =
URL = http://ruby-gnome2.sourceforge.jp/hiki.cgi?tut-gtk2-treev-addrnhs
-------------------------
@@ -9,7 +9,7 @@
Selection information is held for each tree view by a Gtk::TreeSelection object. Every tree view automatically has a Gtk::TreeSelection associated with it, and you can get it using Gtk::TreeView#selection. Selections are handled completely on the tree view side, which means that the model knows nothing about which rows are selected.
-A Gtk::TreeSelection object will automatically be created for you for every Gtk::TreeView, so you will never create one by yourself, therefore it cannot exist independently of this widget. The primary reason the Gtk::TreeSelection objects exists is for cleanliness of code and API. That is, there is no conceptual reason why all these methods would not have been implemented as methods on the Gtk::TreeView widget rather than methods of a separate object.
+A Gtk::TreeSelection object will automatically be created for you for every Gtk::TreeView, so you will never create one by yourself, therefore it cannot exist independently of this widget. The primary reason the Gtk::TreeSelection objects exists is for cleanliness of code and API. That is, there is no conceptual reason why all these methods could not have been implemented as methods on the Gtk::TreeView widget rather than methods of a separate object.
One of the important things to remember when monitoring the selection of a view is that the "changed" signal is mostly a hint, and is unreliable. That is, it may only emit one signal when a range of rows is selected. Additionally, it may on occasion emit a "changed" signal when nothing has happened (mostly as a result of programmers calling select_row on an already selected row). Therefore, it is best to use the signals provided by Gtk::TreeView for selection handling.