Alex Fenton wrote :>1) Setting up event handlers > >In most real apps, I think the most normal way to set up event handlers >is for the event to be dealt with by a corresponding method. At the >moment this has to be done using a block: > >evt_button(AN_ID) { on_button_click } >evt_button(my_button.get_id) do | event | > on_button_click(event) >end >evt_size { | event | on_size(event) } > >So I''d like to suggest as alternatives: > >evt_button(AN_ID, :on_button_click) >evt_button my_button, :on_button_click >evt_size :on_sizeThese are very useful additions especially the second one which removes the need for getting the id of the button, through get_id or wx_id or maybe id (see my post on [wxruby-users] wxRuby 1.9.1 and id accessor consistency problem). I would suggest that the second addition is also reported to the block form. Indeed, there are simple cases where using a block is more simple/practical than defining and using a method. It would be great to have the following addition also : evt_button(my_button) { puts "Button clicked" } This removes the burden of providing explicitly the id of the button.>2) ''each'' for list-like classes > >This one I''m less bothered about, but I fairly often want to loop over a >control with multiple items (eg Choice, ListCtrl, ListBox) to find or >alter a particular item. So for those classes I wonder if we should add >an ''each'' method that passes in turn each valid index into the widget: > >listbox.each { | i | set_item_text(i, item_text(i).upcase) } >Everything that makes wxRuby looks more Ruby is good. Nevertheless, I don''t know if I will use this feature often. Cheers. Chauk-Mean.
Chauk-Mean P wrote:> Alex Fenton wrote : > >> 1) Setting up event handlers >> >>...>> evt_button(AN_ID, :on_button_click) >> evt_button my_button, :on_button_click >> evt_size :on_size >> > > These are very useful additions especially the second one which > removes the need for getting the id of the button, through get_id or > wx_id or maybe id (see my post on [wxruby-users] wxRuby 1.9.1 and id > accessor consistency problem). >Glad you like them. I was going to reply to your last post on wxruby-users that upcoming syntax changes would obviate the most common need to call Window#get_id - but you have beaten me to it :)> I would suggest that the second addition is also reported to the block form.Sure, that was implied. The syntax will be: evt_foo(window_or_id, block_or_symbol)>> listbox.each { | i | set_item_text(i, item_text(i).upcase) } >> >> > > Everything that makes wxRuby looks more Ruby is good. > Nevertheless, I don''t know if I will use this feature often. >The sense I''m getting is that this is a bit marginal. I find it useful to locate the item which has an application object as item_data, when that object is updated elsewhere, eg item_to_update = listbox.each { | i | break i if listbox.item_data(i) == obj } But I think this can probably stay in wxSugar for now a
2007/9/17, Alex Fenton <alex at pressure.to>:> > > Glad you like them. I was going to reply to your last post on > wxruby-users that upcoming syntax changes would obviate the most common > need to call Window#get_idI completely agree. Nevertheless, does that mean that you will keep wx_id ? If this is the case, it''s a pity as it introduces an exception to the "accessor rule". I''d really prefer an id accessor. In addition to the overall consistency, you would not have to add extra documentation :-)> Sure, that was implied. The syntax will be: > > evt_foo(window_or_id, block_or_symbol) >Very cool. I''m looking forward the next version of wxRuby. When is it expected to be released ? Chauk-Mean.
Chauk-Mean P wrote:> Nevertheless, does that mean that you will keep wx_id ? > If this is the case, it''s a pity as it introduces an exception to the > "accessor rule". I''d really prefer an id accessor.I don''t have a strong view - I think I agree with you. Does anyone else have a strong view? If you could point me to some "official" discussion of the deprecation of Object#id and its availability for library/app specific use I''d be convinced to make id mean Wx::Window#id.> Very cool. I''m looking forward the next version of wxRuby. > When is it expected to be released ?Not certain - we''ve just started work on 1.9.2. Given our current release cycle, I''d expect 3-6 weeks. If you''re very eager, try SVN. I''ve recently checked in this change: http://wxruby.rubyforge.org/svn/trunk/wxruby2/lib/wx/classes/evthandler.rb a
2007/9/17, Alex Fenton <alex at pressure.to>:> Chauk-Mean P wrote: > > Nevertheless, does that mean that you will keep wx_id ? > > If this is the case, it''s a pity as it introduces an exception to the > > "accessor rule". I''d really prefer an id accessor. > I don''t have a strong view - I think I agree with you. Does anyone else > have a strong view? If you could point me to some "official" discussion > of the deprecation of Object#id and its availability for library/app > specific use I''d be convinced to make id mean Wx::Window#id.The Ruby for Rails book (David A. Black) p110 gives the whole story of Object#id and Object#object_id. As an example, ActiveRecord is mentioned as using id for the database id which is completely different from the object_id. I hope that this is sufficiently official :-)> > Very cool. I''m looking forward the next version of wxRuby. > > When is it expected to be released ? > Not certain - we''ve just started work on 1.9.2. Given our current > release cycle, I''d expect 3-6 weeks. If you''re very eager, try SVN. I''ve > recently checked in this change: > > http://wxruby.rubyforge.org/svn/trunk/wxruby2/lib/wx/classes/evthandler.rb >Thanks. I will try it. Just for my information, you replied in French to a post, are you french ? Chauk-Mean.
Chauk-Mean P wrote:> 2007/9/17, Alex Fenton <alex at pressure.to>: > >> I don''t have a strong view - I think I agree with you. Does anyone else >> have a strong view? If you could point me to some "official" discussion >> of the deprecation of Object#id and its availability for library/app >> specific use I''d be convinced to make id mean Wx::Window#id. >> > > The Ruby for Rails book (David A. Black) p110 gives the whole story of > Object#id and Object#object_id. As an example, ActiveRecord is > mentioned as using id for the database id which is completely > different from the object_id. > I hope that this is sufficiently official :-) >Thanks. I don''t have that book, but that and the fact that Object#id is removed completely in Ruby 1.9 are good enough for me - unless anyone can think of a reason this is a bad idea.>> Not certain - we''ve just started work on 1.9.2. Given our current >> release cycle, I''d expect 3-6 weeks. If you''re very eager, try SVN. I''ve >> recently checked in this change: >> >> http://wxruby.rubyforge.org/svn/trunk/wxruby2/lib/wx/classes/evthandler.rb >> >> > > Thanks. I will try it. >In this case, you should be able just to copy the .rb file over the existing evthandler.rb without recompiling.> Just for my information, you replied in French to a post, are you french ? >No, I''m English, UK. I think my French would pretty quickly give me away ;) a
2007/9/17, Alex Fenton <alex at pressure.to>:> Chauk-Mean P wrote: > > 2007/9/17, Alex Fenton <alex at pressure.to>: > > > >> I don''t have a strong view - I think I agree with you. Does anyone else > >> have a strong view? If you could point me to some "official" discussion > >> of the deprecation of Object#id and its availability for library/app > >> specific use I''d be convinced to make id mean Wx::Window#id. > >> > > > > The Ruby for Rails book (David A. Black) p110 gives the whole story of > > Object#id and Object#object_id. As an example, ActiveRecord is > > mentioned as using id for the database id which is completely > > different from the object_id. > > I hope that this is sufficiently official :-) > > > Thanks. I don''t have that book, but that and the fact that Object#id is > removed completely in Ruby 1.9 are good enough for me - unless anyone > can think of a reason this is a bad idea.OK. That''s great.> >> Not certain - we''ve just started work on 1.9.2. Given our current > >> release cycle, I''d expect 3-6 weeks. If you''re very eager, try SVN. I''ve > >> recently checked in this change: > >> > >> http://wxruby.rubyforge.org/svn/trunk/wxruby2/lib/wx/classes/evthandler.rb > > > > Thanks. I will try it. > > > In this case, you should be able just to copy the .rb file over the > existing evthandler.rb without recompiling.Yes. I''ve done that (late in the evening or early in the morning) and it works perfectly. Thanks again.> > Just for my information, you replied in French to a post, are you french ? > > > No, I''m English, UK. I think my French would pretty quickly give me away ;) >I noticed that your english was better than your french but I supposed that you left France a long time ago : - ). Now I understand the reason. A big cheer for the translation effort of your reply : - ) As far as I''m concerned and despite my uncommon first name, I''m french. Cheers. Chauk-Mean.
2007/9/17, Alex Fenton <alex at pressure.to>:> >>2) ''each'' for list-like classes > >> > >>This one I''m less bothered about, but I fairly often want to loop over a > >>control with multiple items (eg Choice, ListCtrl, ListBox) to find or > >>alter a particular item. So for those classes I wonder if we should add > >>an ''each'' method that passes in turn each valid index into the widget:> >> listbox.each { | i | set_item_text(i, item_text(i).upcase) } > >> > >> > >> > > Everything that makes wxRuby looks more Ruby is good. > > Nevertheless, I don''t know if I will use this feature often. > > > The sense I''m getting is that this is a bit marginal. I find it useful > to locate the item which has an application object as item_data, when > that object is updated elsewhere, eg > > item_to_update = listbox.each { | i | break i if listbox.item_data(i) => obj } > > But I think this can probably stay in wxSugar for now >Alex, It seems that your proposal is more useful than I first thought. Indeed, for a CheckListBox, there is no method for returning an array of indexes for the items that are checked. Such a method is similar as the ''selections'' method (from ListBox) that returns an array of indexes for the items that are selected. Consequently, one must iterate over all item indexes of the CheckListBox and call ''checked?'' to see if the item is checked or not. a) So an each method will ease the coding of such a ''checks'' method b) Don''t you think that such a ''checks'' method is valuable for adding to the CheckListBox ? Cheers. Chauk-Mean.