[#8566] Visions for 2001/1.7.x development? — Robert Feldt <feldt@...>

Hi matz and other Ruby developers,

18 messages 2001/01/03
[#8645] Re: Visions for 2001/1.7.x development? — matz@... (Yukihiro Matsumoto) 2001/01/04

Hi,

[#8580] bug?? — jmichel@... (Jean Michel)

I don't understand the following behaviour:

19 messages 2001/01/03

[#8633] Interesting Language performance comparisons - Ruby, OCAML etc — "g forever" <g24ever@...>

13 messages 2001/01/04

[#8774] No :<, :>, etc. methods for Array — "Brian F. Feldman" <green@...>

So, why not include Comparable in Array by default? It shouldn't have any

28 messages 2001/01/07
[#8779] Re: No :<, :>, etc. methods for Array — matz@... (Yukihiro Matsumoto) 2001/01/07

Hi,

[#8780] Re: No :<, :>, etc. methods for Array — "Brian F. Feldman" <green@...> 2001/01/07

matz@zetabits.com (Yukihiro Matsumoto) wrote:

[#8781] Re: No :<, :>, etc. methods for Array — gotoken@... (GOTO Kentaro) 2001/01/07

In message "[ruby-talk:8780] Re: No :<, :>, etc. methods for Array"

[#8782] Re: No :<, :>, etc. methods for Array — "Brian F. Feldman" <green@...> 2001/01/07

gotoken@math.sci.hokudai.ac.jp (GOTO Kentaro) wrote:

[#8829] Sandbox (again) — wys@... (Clemens Wyss)

Hi,

20 messages 2001/01/08
[#8864] Re: Sandbox (again) — Clemens Hintze <c.hintze@...> 2001/01/08

On 8 Jan, Clemens Wyss wrote:

[#8931] String confusion — Anders Bengtsson <ndrsbngtssn@...>

Hello everyone,

21 messages 2001/01/09
[#8937] Re: String confusion — matz@... (Yukihiro Matsumoto) 2001/01/09

Hi,

[#8953] Please remove account from files — "Thomas Daniels" <westernporter@...>

Please take my e-mail address from your files and "CANCEL" my subscription to "Ruby-Talk". Ruby is not right for what I do. The "Bulk Mail" is overwhelming. Please, no more e-mail! Thank you! yours truly, Stan Daniels

14 messages 2001/01/09
[#8983] Re: Please remove account from files — John Rubinubi <rubinubi@...> 2001/01/10

On Wed, 10 Jan 2001, Thomas Daniels wrote:

[#9020] time to divide -talk? (was: Please remove account from files) — Yasushi Shoji <yashi@...> 2001/01/10

At Wed, 10 Jan 2001 14:23:30 +0900,

[#9047] Re: time to divide -talk? (was: Please remov e account from files) — Aleksi Niemel<aleksi.niemela@...>

Yasushi Shoji:

27 messages 2001/01/10
[#9049] Re: time to divide -talk? — Yasushi Shoji <yashi@...> 2001/01/10

At Thu, 11 Jan 2001 00:20:45 +0900,

[#9153] what about this begin? — Anders Strandl Elkj誡 <ase@...> 2001/01/11

[#9195] Re: Redefining singleton methods — ts <decoux@...>

>>>>> "H" == Horst Duch=EAne?= <iso-8859-1> writes:

10 messages 2001/01/12

[#9242] polymorphism — Maurice Szmurlo <maurice@...>

hello

73 messages 2001/01/13

[#9279] Can ruby replace php? — Jim Freeze <jim@...>

When I read that ruby could be used to replace PHP I got really

15 messages 2001/01/14

[#9411] The Ruby Way — "Conrad Schneiker" <schneiker@...>

As a member of the "Big 8" newsgroups, "The Ruby Way" (of posting) is to

15 messages 2001/01/17

[#9462] Re: reading an entire file as a string — ts <decoux@...>

>>>>> "R" == Raja S <raja@cs.indiana.edu> writes:

35 messages 2001/01/17
[#9465] Re: reading an entire file as a string — Dave Thomas <Dave@...> 2001/01/17

raja@cs.indiana.edu (Raja S.) writes:

[#9521] Larry Wall INterview — ianm74@...

Larry was interviewed at the Perl/Ruby conference in Koyoto:

20 messages 2001/01/18
[#10583] Re: Larry Wall INterview — "greg strockbine" <gstrock@...> 2001/02/08

Larry Wall's interview is how I found out

[#9610] Re: 101 Misconceptions About Dynamic Languages — "Ben Tilly" <ben_tilly@...>

"Christian" <christians@syd.microforte.com.au> wrote:

13 messages 2001/01/20

[#9761] Re: 101 Misconceptions About Dynamic Languages — ts <decoux@...>

>>>>> "C" == Christoph Rippel <crippel@primenet.com> writes:

16 messages 2001/01/23

[#9792] Ruby 162 installer available — Dave Thomas <Dave@...>

15 messages 2001/01/24

[#9958] Re: Vim syntax files again. — "Conrad Schneiker" <schneik@...>

Hugh Sasse wrote:

14 messages 2001/01/26
[#10065] Re: Vim syntax files again. — Hugh Sasse Staff Elec Eng <hgs@...> 2001/01/29

On Sat, 27 Jan 2001, Conrad Schneiker wrote:

[#9975] line continuation — "David Ruby" <ruby_david@...>

can a ruby statement break into multiple lines?

18 messages 2001/01/27
[#9976] Re: line continuation — Michael Neumann <neumann@...> 2001/01/27

On Sat, 27 Jan 2001, David Ruby wrote:

[#9988] Re: line continuation — harryo@... (Harry Ohlsen) 2001/01/28

>A statement break into mutliple lines if it is not complete,

[ruby-talk:9968] [SOLUTION] Re: Ruby/Tk -- Creating a class with Labels and Buttons that talk to each other

From: jfn@... (Jeremy Nelson)
Date: 2001-01-27 00:40:08 UTC
List: ruby-talk #9968
Sorry to follow up on my own post, but a workable solution has been arrived
at and it is general purpose, and it seems to work, and so I'd like to share
it with the world becuase I can't be the only one who has ever had this
come up! =)

This explanation is kind of geared towards ruby newbies, so you advanced
users please bear with me. =)

What I had tried to do was create a class that created several different
Tk widgets, and created a "button box", where the totality of the whole
thing was an easy way for a user to input a number to the application.

When the user presses a button, that button (remember, there is a plurality
of them) needs to be able to "talk to" a Tk label widget which will show
the number on that button.  This way the user can see what buttons they 
pushed.  The problem was how to get an arbitrary number of buttons to 
talk to a single widget.  

I was trying to solve this problem with TkVariables, and that was fine, 
but I could not figure out how to create a TkVariable in each instantiation
of a class and then refer to that TkVariable in the callbacks to the various
TkButtons.

The solution to this is to convert the instance variable to another type
(ie, a local variable).  Because all variable names in ruby are actually
references to some underlying object, it does not matter exactly what type
of variable name you choose to refer to an object; the only thing that 
matters is whether or not that variable name is in scope (visible) in the 
place where you want to use it.

Thus, the solution to this problem is the following code:

class Grid                                                           #  1
        def localvar= (x)                                            #  2
                @localvar.value = x.to_s                             #  3
        end                                                          #  4

        def initialize (parent, rows, columns)                       #  5
                @localvar = TkVariable.new()                         #  6
                @localvar.value = ""                                 #  7
                foo = @localvar                                      #  8

                TkLabel.new(parent) { textvariable foo }.pack        #  9
                @frame = TkFrame.new(parent).pack                    # 10

                argh = self.method("localvar=")                      # 11
                rows.times { |i|                                     # 12
                   columns.times { |j|                               # 13
                        currval = (i * rows + j).to_s                # 14
                        TkButton.new(@frame) {                       # 15
                                command proc {                       # 16
                                        argh.call(self.text)         # 17
                                }                                    # 18
                                text    currval                      # 19
                                grid ( 'row' => i, 'column' => j)    # 20
                        }                                            # 21
                   }                                                 # 22
                }                                                    # 23
        end                                                          # 24
end                                                                  # 25

mw = TkRoot.new                                                      # 26

Grid.new(mw, 5,5)                                                    # 27
Grid.new(mw, 6,6)                                                    # 28
Tk.mainloop                                                          # 29

[explanation]
On line 6, I create the TkVariable that we will be using to coordinate the
"talking" between each of the TkButtons and the TkLabel.  Ruby's rules do
not permit @localvar to be in scope in the option block to TkLabel.new, 
because it is an instance variable in another class (as far as I understand).
However, you can take advantage of local variables always being in scope in
the current function and create a reference to @localvar to a local variable
in line #8 -- now you can use 'foo' as the argument to 'textvariable' in the
TkLabel!

The other problem is what the buttons will do when they are pressed.  They
need to call a method, but they do not have any way to identify with the 
object that they 'belong' to.  So in line 11, we create a local variable
that points to 'self.localvar=', and since that is a local variable, it will
be in scope in any option lists to Tk widgets!.  So in line 17, in the Tk
callback for each button, we tell it to "call" the method that we have created
a local variable reference to in line 11.  This permits each button to know
not only what function to call, but also which object to call that function!

The function that sets the value of our TkVariable is on lines 2, 3, and 4.
It basically just calls the "value=" method for the TkVariable object that
we have.  And since we have a name for that TkVariable visible throughout
the class (@localvar) we can use it.

Thanks for bearing with me!  I'm excited!  This is neat!  I've used 
entirely too many bangs in this posting! ;-)

Jeremy

In This Thread

Prev Next