Why does Gtk::Dialog::run go into TreeViewColumn::initialize?

Desktop Ruby-Gnome 2
1

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
load_glade(FILE)
@builder[“window1”].title = “Edit Grammar Rule”
@builder[“label”].text = @info.to_s
super
end

def run
puts “TestDialog run called”
super
puts “Back from run”
end

end

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

When I call

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

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
initialize).

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!

2

Hi:

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:

http://visualruby.net/VR/Dialog.html

@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
Modal.

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.

Best,
Eric

3

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”
MyWindow.new.show
puts “bar”
end

and when I pressed my_button it would say

foo

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 MyChildClass.glade from the
example, verified that it did work properly, diff’d the glade files
between MyWindow.glade and MyChildClass.glade, copied lines back and
forth, and narrowed it down to a line that was missing from
MyWindow.glade

I did mention I’d inherited old code? I’ve been editing MyWindow.glade
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
old-style.

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

Thanks!

4

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.

Thanks,
Chris

5

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

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! :slight_smile:

Yours,
Eric