I’m trying to process the focus changed event without success. I’m only
interested in it if it is a particular control losing focus, but (so
far) I haven’t been able to get it processed at all. In the event setup,
I use the following:
evt_kill_focus() {|event| focus_changed(event)}
in the focuschanged I do the following
def focus_changed(event)
if event.get_window.id == @endbox.id#Test whether I’m
interested
------
best I can tell, the focus_changed is never called. Could someone point
out the right way to do this?
I think evt_kill_focus is one of those events you have to define inside
the
class that will be using it, since it doesn’t take an id parameter. If
you
don’t have a specific class for that one control (which is most of the
time), the somewhat-hacky solution I’ve used in the past would look
something like:
class << @endbox
def setup_focus_event(&block)
evt_kill_focus(&block)
end
end
While it’s admittedly not a very pretty or probably very elegant
solution,
it works for me, and has the side-effect of no longer requiring that you
check to make sure the event is firing on the control you’re interested
in.
I think evt_kill_focus is one of those events you have to define
inside the class that will be using it, since it doesn’t take an id
parameter. If you don’t have a specific class for that one control
(which is most of the time), the somewhat-hacky solution I’ve used in
the past would look something like:
Yes, see the discussion of the distinction between CommandEvents (which
“bubble” upwards) and others (which are notified to their generator
only).
I’ve recently had to solve a similar problem in my own code (catching an
evt_motion on a Wx::ListBox to pop up a custom tooltip), and after
writing
out what I wrote here, I had a crazy idea which made me feel really
ridiculous:
@endbox.focus_event(:focus_changed)
…
def focus_changed(event)
# do stuff
end
I’m not positive of the :focus_changed part or if you’d still have to
pass a
block, but I know Command events you can pass method names like that. I
think it’s a far more elegant solution than what I wrote previously.
–Stephen
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.