Forum: Ruby-Gnome 2 Why does Gtk::Dialog::run go into TreeViewColumn::initialize?

Announcement (2017-05-07): is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see and for other Rails- und Ruby-related community platforms.
7e6cdf272a7177072fecd8e019bcf6f7?d=identicon&s=25 Chris Phoenix (chrisphoenix)
on 2014-04-08 04:44
I'm trying to pop up a modal dialog. In TestDialog.rb I put

class TestDialog < Gtk::Dialog
  include GladeGUI

  attr_reader :info

  def initialize
    @info = 5
    @builder["window1"].title = "Edit Grammar Rule"
    @builder["label"].text = @info.to_s

  def run
    puts "TestDialog run called"
    puts "Back from run"


I make a file with the label, using a GtkDialog
top-level with name: window1.

When I call

      rhs_editor =
      puts "About to call run in GR:Init"

and put a breakpoint on the "super" in the run method, and step-in in
RubyMine, it goes straight to line 53 of TreeViewColumn.rb (in the block
passed to set_cell_data_func in the "user defined object" section of

But TestDialog is inheriting straight from Gtk::Dialog. It should have
nothing to do with VR. I do use VR elsewhere in my program, but I put a
breakpoint on the call to set_cell_data_func and it's not being called
from that class.

All I really want to do is put up a modal dialog-like window that I
define in Glade, and get an answer from it before I continue. I've spent
six hours on it today. Help??? Thanks!
0d130f179f85401f248e6ebc2ef8292f?d=identicon&s=25 Eric C. (eric_c)
on 2014-04-08 23:02

You're making it a bit more complicated than it needs to be.  I don't
understand the callstack, but let me give you another path to try.

First, if all you want to do is pop-up a box and get an answer, use the
input_box() method:

@answer = VR::Dialog.input_box("Give me answer:", "5", title = "Edit
Grammar Rule")

I don't see any reason to subclass Gtk::Dialog.  Visual Ruby  is
naturally made to create windows easily, and the windows default to

Also, the load_glade(__FILE__) method is no longer needed  in your code.
visualruby loads the glade file automatically now.  I don't think it
belongs in the initialize method anyway.

Take a look at the example programs in visualruby.  They show the new
way of doing things.  Now, you just define a method named before_show()
to do any tasks you want done before the window appears on the screen.
On many occasions, initialize isn't even necessary.

These two lines:

    @builder["window1"].title = "Edit Grammar Rule"
    @builder["label"].text = @info.to_s

are just setting constant values in your glade form.  I would suggest
using the glade program to set those values so you unclutter your code.
But its great that you understand how to manipulate them with code too.

Let me know how it goes.

7e6cdf272a7177072fecd8e019bcf6f7?d=identicon&s=25 Chris Phoenix (chrisphoenix)
on 2014-04-10 10:56
Many thanks! I found the problem... after another 2 hours of debugging.
It's a fun one.

I was indeed using "old-style" code that I inherited (from myself,
months ago, when I was first learning Glade/VR/Gtk).

(Also, I had missed the instructions on how to create the examples
directory during install (I use RubyMine as my IDE, so never tried to
run the VR IDE), and I kept looking on the "child windows" tutorial page
and in the sidebar for a link to download the code.)

Worst of all... even when I converted my code to "new style" it kept
not-continuing after the modal window was closed. I could say

def my_button__pressed
  puts "foo"
  puts "bar"

and when I pressed my_button it would say


and then put up the window, and then I'd close the window, and then...
it would not say "bar." It just wouldn't execute the rest of the code in
the method.

I finally copied in MyChildClass.rb and from the
example, verified that it did work properly, diff'd the glade files
between and, copied lines back and
forth, and narrowed it down to a line that was missing from

 <signal name="destroy" handler="destroy_window" swapped="no"/>

I did mention I'd inherited old code? I've been editing
with the new Glade, but apparently Glade didn't notice that that line
was missing, didn't add it, and didn't warn me that the glade file was

If there are other people out there who've inherited old .glade files,
that would be a nice feature to put into Glade.

0d130f179f85401f248e6ebc2ef8292f?d=identicon&s=25 Eric C. (eric_c)
on 2014-04-10 22:29
Now I understand.

One of the great things about visualruby is that it does all the
parent/child windows and closing of windows automatically.

The reason you ran into this problem is because you likely created the
form from scratch using glade.  When you create a new form with
visualruby, it copies a skeleton glade file from the "skeleton" folder.
This glade file already has the "destroy" event set to "destroy_window".
Visualruby's library, vrlib (GladeGUI) has the destroy_window defined in
it, so you can simply use the destroy_window() method anywhere in your

It might be best to use the visualruby IDE because it knows to create
new glade files in this way.  Also, it helps you organize your files
because you just right-click on any program file to create the
corresponding glade file.  And it knows the naming conventions.

In your case it would have saved you hours of debugging.

But now you know how it creates new glade files!  :)

7e6cdf272a7177072fecd8e019bcf6f7?d=identicon&s=25 Chris Phoenix (chrisphoenix)
on 2014-04-10 22:38
Yes - indeed I created the forms/windows using Glade.

Learning a second IDE would also have cost me hours.

A brief note in the tutorial about the importance of using VR-created
Glade files would have saved me hours...? It just doesn't seem obvious,
to someone who starts using Ruby first and then finds VR, that they
can't just use the VR library with off-the-shelf Glade.

This topic is locked and can not be replied to.