«

hi

when I'm using a connect method, how do I tell fxruby that the event
has been handled by my routine and to stop processing, or, that I
haven't handled the event and proceed as normal? Particularly with
keypresses I want to handle some specific key strokes, but if I don't,
I want to let everything run as normal and the key to be entered into
the field automatically.

On a separate note when is the 1.4 branch of fxruby likely to be
available , can't get enough, it's working very well.

Thx

R

On 8/16/05, ritchie <> wrote:

> when I'm using a connect method, how do I tell fxruby that the event
> has been handled by my routine and to stop processing, or, that I
> haven't handled the event and proceed as normal? Particularly with
> keypresses I want to handle some specific key strokes, but if I don't,
> I want to let everything run as normal and the key to be entered into
> the field automatically.

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".

> On a separate note when is the 1.4 branch of fxruby likely to be
> available , can't get enough, it's working very well.

Most of the code is checked in, and I'm going through the examples to
get them up to date. Hope to have a first release of FXRuby 1.4 within
a week!

Lyle Johnson <> 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?

martin

On 8/17/05, Martin DeMello <> wrote:

> Lyle Johnson <> 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".
>=20
> 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 =3D=3D 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

Lyle

thanks for the info on the event handling, works a treat.
my next question is about drag n drop. i'm having a bit of difficulty
dnd from an FXIconList. I want to pick up an icon and drag it to
another iconlist, this is possible yes?

FYI, on the iconlist, the retrieveItem method does not exist, although
it's documented in the help, getItem() seems to work though, which I
found in the unit tests but as far as i can see is not documented, in
rdoc anyway.

thanks

R

On 8/17/05, ritchie <> wrote:

> thanks for the info on the event handling, works a treat.
> my next question is about drag n drop. i'm having a bit of difficulty
> dnd from an FXIconList. I want to pick up an icon and drag it to
> another iconlist, this is possible yes?

I guess so, I've never tried it. You might ask on the foxgui-users
mailing list to see if anyone's tried to do this.

> FYI, on the iconlist, the retrieveItem method does not exist, although
> it's documented in the help, getItem() seems to work though, which I
> found in the unit tests but as far as i can see is not documented, in
> rdoc anyway.

Thanks. I've added a bug report for this:

http://rubyforge.org/tracker/index.p...D2260&group_i=
d=3D300&atid=3D1223

-- Lyle

P.S. If there are follow-up questions, let's take them over to the
fxruby-users mailing list since ruby-talk is intended for more general
Ruby discussions.

Lyle Johnson <> wrote:
>
> 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.

That's a pretty neat use of 'false' as a distinguished singleton object,
actually.

martin