Ruby/Tk: how to get Scrollbar to stay scrolled?


#1

Hello all,

I am trying to get a new grid control working (similar to a TreeView
without the tree) and my most recent problem is to get the Scrollbar to
respond to the changes it initiates in the grid. I’ve tried a few
things, but nothing on the web seems to deal with getting a Scrollbar to
work with anything that isn’t already inside Tk and has the correct
hooks. The closest I’ve come is some allusions at
http://www.tkdocs.com/tutorial/onepage.html

The code I was trying includes this just after the widgets are setup:

@v_scroll.command proc{|*args| self.yview(*args)}

self.yscrollcommand proc{|*args| @v_scroll.set(*args)}

self.yscrollcommand proc{|*args|
@v_scroll.set(@y_scroll_start_fraction, @y_scroll_end_fraction)}

The scrollbar responds since I defined yview to send to internal
yviewMoveTo and yviewScroll methods (as I found somewhere else): the
move commands are sent to the correct methods. However once the user
releases the scrollbar, the scrollbar always returns to the original
position (top).

I tried defining it the same as in existing widgets, eg:
def yscrollcommand block
configure_cmd ‘yscrollcommand’, block
self
end

But even if I include TkConfigMethod and TkComm in the class, it can’t
figure out what TkConfigMethod’s path is (and I certainly don’t know).
I also tried some other things like using the standard *args version
above and have this definition of yscrollcommand:

block.call(@y_scroll_start_fraction, @y_scroll_end_fraction)

But apparently I am missing some deeper understanding of what the
process is here… Since yscrollcommand seems to only be called at the
start, I figure the contents have to be linking a block to something
else, but the definitions in tk.rb didn’t clear anything up for me. It
seems like a lot of code acrobatics behind configure_cmd() - do I need
that?

Has anyone been successful at this or can tell me what I should be
trying instead?

Thanks!

-Chris


#2

Sorry for replying to myself, but I just stumbled on a possible
solution: using the typical
@v_scroll.set(@first_viz,@last_viz)
at the end of the yview() declaration. In my few trials it seems to
work even though it doesn’t fit in the prescribed callback mechanism
that every book and website describes. Which, incidentally, is why I
didn’t think of it sooner.

Does this add a problem that will bite me later?