On 8/17/05, Martin DeMello <martindemello / yahoo.com> wrote:

> Lyle Johnson <lyle.johnson / gmail.com> wrote:
> >
> > If the result of evaluating the event handler block or method is
> > false, or the number zero, the event is considered "unhandled" and so
> > the widget's key handling code should continue to do its thing. If the
> > result of the handler block or method is any other value (e.g. true,
> > or 1, or nil, whatever) the event is considered "handled".
> 
> Why the false/nil split?

Good question; it's for a combination of reasons.

A lot of the instance methods for FOX classes return nil, and it's
often the case that you're calling one of these methods in your
message handler, e.g.

    # When user clicks the startButton, show the progress dial
    startButton.connect(SEL_COMMAND) {
      progressDial.show
    }

Now, as is, this block has a nil result (because the show() method
returns nil). At the same time, we want FOX to understand that this
block successfully handled the SEL_COMMAND message it was sent, so
that's how we arrived at the mapping that a nil result for a block
evaluation equates to "message handled". If we had gone with the
opposite approach, that a nil result equates to "message not handled",
we'd end up with something awkward like:

    # When user clicks the startButton, show the progress dial
    startButton.connect(SEL_COMMAND) do
      progressDial.show
      true
    end

Now, we still need some way to signal the rarer case that a message
wasn't handled, e.g.

    textField.connect(SEL_KEYPRESS) do |sender, sel, event|
      if event.code == KEY_Left
        do_something
      else
        # need to indicate that the message wasn't handled, and
        # that regular FOX keypress handling needs to take over
        false
      end
    end

If you're going to explicitly encode the block result, it makes sense
that a false result means "message not handled", even though that's
inconsistent with the general Ruby truth that false and nil are
(somewhat) equivalent.

It's a little messy, but for the majority of cases (where the message
is successfully handled), it's not something you ever notice.

Hope this helps,

Lyle