# Adding a handler proc after the fact to GladeXML

**URL:** <https://www.ruby-forum.com/t/adding-a-handler-proc-after-the-fact-to-gladexml/174973>\
**Category:** Ruby-Gnome 2\
**Created:** [September 5, 2009, 12:16am UTC](https://www.ruby-forum.com/t/adding-a-handler-proc-after-the-fact-to-gladexml/174973 "2009-09-05T00:16:26Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![matthew](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/ed655f/32.png) [@matthew](https://www.ruby-forum.com/u/matthew)\
**Post date:** [September 5, 2009, 12:16am UTC](https://www.ruby-forum.com/t/adding-a-handler-proc-after-the-fact-to-gladexml/174973/1 "2009-09-05T00:16:26Z")

</div>

Hi,

I need to be able to set a handler after GladeXML.new. Is this possible?

Instead of this:  
@glade = GladeXML.new(path\_or\_data, root, domain,localedir,  
flag) {|handler| method(handler)}

I’d like to do this:  
@glade = GladeXML.new(path\_or\_data, root, domain,localedir, flag)  
…  
@glade.handler\_proc = {|handler| method(handler)}

Or even

my\_handler = {|handler| method(handler)}  
…  
@glade = GladeXML.new(path\_or\_data, root, domain,localedir, flag)  
…  
@glade.handler\_proc = {|handler| method(handler)}

Will any of these options work?

–  
Cheers,

Matt.

“Why are the pretty ones always insane?” - Clancy Wiggum

---

<div class="post-metadata">

**Author:** ![matthew](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/ed655f/32.png) [@matthew](https://www.ruby-forum.com/u/matthew)\
**Post date:** [September 5, 2009, 5:45pm UTC](https://www.ruby-forum.com/t/adding-a-handler-proc-after-the-fact-to-gladexml/174973/2 "2009-09-05T17:45:24Z")

</div>

Ian McIntosh wrote:

> Hi,
> 
> Saw your post to the ruby-gnome mailing list.
> 
> Why do you need to do that?

Well, I’m creating a remote gui client so I can deploy a rich network  
application. It uses DRb so the client connects to the server and passes  
_up_ (via the front object) a gui management object. This gui management  
object has functions allowing the server to create widgets (or other  
objects) at the client end. Works fine for raw GTK, but Glade brings  
some interesting challenges.

So, all the logic (including event handlers) are defined at the server  
and I need a way of getting the handlers attached to the GladeXML object  
as I haven’t figured out a way of passing a block during object creation  
which, incidentally, looks like this:

def create\_object(class\_name, \*instance\_parameters)  
new\_class\_ref = Object  
class\_name.split(‘::’).each { |c|  
new\_class\_ref = new\_class\_ref.const\_get(c)  
}  
new\_object = new\_class\_ref.new(\*instance\_parameters)  
@widgets[new\_object.object\_id] = new\_object  
return new\_object  
end

I have created the GladeXML, and I have created an object containing  
suitably named handlers (which lives on the server with a DRb proxy  
object passed down to the client) but I’m currently trying to figure out  
how to wire the two together. Maybe I should migrate to 1.9 which as  
String#to\_proc apparently, but I want 1.8 compatibility if possible.

> This is what I use:  
> [~ian-mcintosh/luz/trunk : contents of utils/glade\_window.rb at revision 2167](http://bazaar.launchpad.net/~ian-mcintosh/luz/trunk/annotate/head%3A/utils/glade_window.rb)

I’ll take a look at this tomorrow - off to sleep for now!

Thanks!

Matt

---

<div class="post-metadata">

**Author:** ![matthew](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/ed655f/32.png) [@matthew](https://www.ruby-forum.com/u/matthew)\
**Post date:** [September 5, 2009, 11:56pm UTC](https://www.ruby-forum.com/t/adding-a-handler-proc-after-the-fact-to-gladexml/174973/3 "2009-09-05T23:56:35Z")

</div>

In case anyone was interested, my solution was:

- Create a class containing the event handlers on the server.
- Create a wrapper class containing the GladeXML object on the client.
- In the handler creation block, dynamically create local (i.e. in the  
wrapper class) instance methods with the same name as the glade signal  
and the remote handler function. Local functions call remote ones of  
the same name via DRbObject#missing\_method.

–  
Cheers,

Matt.

“The idea that an arbitrary naive human should be able to properly use a  
given tool without training or understanding is even more wrong for  
computing than it is for other tools (e.g. automobiles, airplanes, guns,  
power saws).” - Doug Gwyn