wxruby users - Jun 2004 - Handling Events that don''t take an ID

Hey Kevin,

Am I correct in assuming that if I want a particular widget to respond to an 
event which doesn''t take an ID as an argument (like evt_size or 
evt_left_down), that I have to inherit a new widget and define the event 
handler within the inherited class?  Here''s a little contrived code
example
to illustrate what I mean:

class MyCtrl < Wx::TextCtrl
  def initialize()
      evt_size {|event| on_size(event)}
  end

  def on_size(event)
      # Do whatever
  end
end

Or is there a simpler, more direct way to get a particular instance of a 
widget to respond to such events?

Robert Carlin

_________________________________________________________________
Watch the online reality show Mixed Messages with a friend and enter to win 
a trip to NY 
http://www.msnmessenger-download.click-url.com/go/onm00200497ave/direct/01/

Hiya,

Robert Carlin wrote:
> Am I correct in assuming that if I want a particular widget to respond 
> to an event which doesn''t take an ID as an argument (like evt_size
or
> evt_left_down), that I have to inherit a new widget and define the event 
> handler within the inherited class?  
I think that''s right. That is a disadvantage of not taking an ID 
argument. Not taking an ID simpler if you do have a subclass, but harder 
if you didn''t want a subclass.

We should look at how wxPython handled this, and match them if the 
"solved" it. Otherwise, we should figure out the best compromise
between
simplicity, compatibility, and ease of use.

Thanks,

Kevin

I am using WxGrid for a miniSpreadsheet application. When a user
enter''s a
formula (=a1+b1) I am then calculating the values of cell a1 + value of cell
b1. This works great. I do this by intercepting the evt_key_down when the
user hits the enter key. It will check to see if the value is a formula or
not. If it is I calculate the new value and then replace the cell''s
value
with the calculated one.

I need to be able to do this when the user uses his mouse to select another
cell, causing the selected cell to lose focus.

ie: I click  cell a1, start typing...=a5+b5, instead of hitting the enter
key to save i use my mouse and go click on cell a6.

I would like to be able to intercept this. I know the mouse event handlers
arent currently working with WxGrid, but maybe someone knows something I do
not?

Thanks,

ZAch
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.692 / Virus Database: 453 - Release Date: 5/28/2004

>We should look at how wxPython handled this, and match them if the
"solved"
>it. Otherwise, we should figure out the best compromise between simplicity, 
>compatibility, and ease of use.
wxPython handles this by having two versions of event handlers - one that 
takes an id and a method, and one that takes the actual widget in question 
and a method.  So if you had a Wx::TextCtrl named text1 and wanted it to 
respond to a size event (for whatever reason), in wxPython you would write

EVT_SIZE(text1, onEventSize)

So maybe we could have something equivalent, that would take a widget as the 
argument or the ID (is this feasible?), and bind it to the event.  That 
would definitely make things simpler.

Robert

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar – get it now! 
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/

Robert Carlin wrote:
> wxPython handles this by having two versions of event handlers - one 
> that takes an id and a method, and one that takes the actual widget in 
> question and a method.  
> 
> EVT_SIZE(text1, onEventSize)
So they overload it, such that this also works, defaulting to self as 
the widget?:

EVT_SIZE(onEventSize)
> So maybe we could have something equivalent, that would take a widget as 
> the argument or the ID (is this feasible?), and bind it to the event.  
> That would definitely make things simpler.
Yup, we could do that. I think we could even accept an ID or widget as 
the first parameter.

It would be great if you could add this to the Feature Requests section 
of the wxruby rubyforge site.

Thanks,

Kevin

Kevin wrote:
>So they overload it, such that this also works, defaulting to self as the 
>widget?:
>
>EVT_SIZE(onEventSize)
Sorry Kevin, in my haste I forgot to go into this :-(

All event handlers defined within an inheriting class take "self" as
the
first argument, so for the SizeEvent it would be EVT_SIZE(self, 
onEventSize).  Event handlers that require an ID in wxPython take the 
following form of EVT_XXX(Control, ID, method).  It seems to me that any 
widget can be used as the first argument, as long as it exists.  The ID has 
to be for the specific widget you want to respond to EVT_XXX.  Here is the 
following example that I concocted in wxPython to try to illustrate - I hope 
it helps out:

from wxPython.wx import *
app = wxPySimpleApp()
frame = wxFrame(None, -1, "Hello World")
button = wxButton(frame, -1, "Button")

def onClose(event):
    print "Close"
    event.Skip()

def onButton(event):
    print "Button"

EVT_CLOSE(frame, onClose)
EVT_BUTTON(button, button.GetId(), onButton)
#EVT_BUTTON(frame, button.GetId(), onButton)

frame.Show(1)
app.MainLoop()

The EVT_BUTTON() handler that is commented out prints out "Button" the
same
as the first one that isn''t commented out - I guess this just gives the
programmer extra flexibility.  Sorry I forgot to clarify this in the earlier 
post :-)

Robert

_________________________________________________________________
Get fast, reliable Internet access with MSN 9 Dial-up – now 3 months FREE! 
http://join.msn.click-url.com/go/onm00200361ave/direct/01/

Zach Dennis wrote:
> I am using WxGrid for a miniSpreadsheet application. 
> I need to be able to do this when the user uses his mouse to select another
> cell, causing the selected cell to lose focus.
> 
> I would like to be able to intercept this. I know the mouse event handlers
> arent currently working with WxGrid, but maybe someone knows something I do
> not?
Unfortunately, I can''t think of any workaround to get this working
right
now.

Kevin

Robert Carlin wrote:
> EVT_CLOSE(frame, onClose)
> EVT_BUTTON(button, button.GetId(), onButton)
> #EVT_BUTTON(frame, button.GetId(), onButton)
Ugh. Maybe we should support that for compatibility, but 90% of the 
time, I want to pass ONLY the block (or maybe a symbol naming a method).

I guess the decision is whether we should have a single overloaded 
version, or multiple separate versions. Something like this:

  evt_button(:on_click)
  evt_button {on_click}
  evt_button(id, :on_click)
  evt_button(id) {on_click}
  evt_button(button, :on_click)
  evt_button(button) {on_click}

OR something like this:

  evt_button(:on_click)
  evt_button {on_click}
  evt_button_id(id, :on_click)
  evt_button_id(id) {on_click}
  evt_button_object(button, :on_click)
  evt_button_object(button) {on_click}

Kevin

Kevin,

Sorry, I didn''t mean to imply that we should simply copy
wxPython''s style -
I just wanted to show it as an example.  Personally I am with you - I just 
want to pass the block.  I don''t know how feasible it would be, but I 
personally would love it if we could pass the widget or its id for methods 
that currently just take a block.  So instead of writing

evt_size {|event| on_size(event)}

I could write

evt_size(button) {|event| on_size(event)}.

It would also be cool if there was a way to have the first type of 
declaration which would simply default to the class it was defined in 
(again, this is just pie in the sky, but I do love pie :-)

Robert

_________________________________________________________________
Check out the coupons and bargains on MSN Offers! http://youroffers.msn.com

Kevin Smith wrote:
> I guess the decision is whether we should have a single overloaded 
> version, or multiple separate versions. Something like this:
Though method overloading isn''t that common in the core Ruby API, but I
think this is good place for it.
>  evt_button(:on_click)
>  evt_button {on_click}
>  evt_button(id, :on_click)
>  evt_button(id) {on_click}
I''m not so keen on MO where the arguments switch positions - ie the 
symbol moving from first to second here. I''d rather

evt_button(:on_click) # default target
evt_button(:on_click, button_or_button_id)

But I guess this is a backwards compat no-go. Or different meth names?
>  evt_button_id(id, :on_click)
>  evt_button_id(id) {on_click}
>  evt_button_object(button, :on_click)
>  evt_button_object(button) {on_click}
The use of widget IDs in WxRuby sometimes feels like an implementation 
detail that I don''t want to care about, and this is one of those here.

evt_button(button_or_button_id, :on_click)

Looks delightful to my eye, but still lets people who need or require 
IDs to use them.

Thanks
alex