Ruby/Tk: how to get Scrollbar to stay scrolled on non-scroll widget?


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

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 it always returns to the original position.

I tried defining it the same as in existing widgets, eg:
def yscrollcommand block
configure_cmd ‘yscrollcommand’, block
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:, @y_scroll_end_fraction)
But apparently I am missing some deeper understanding of what the
process is here.

Has anyone been successful at this, or otherwise knows what kind of
abstraction histrionics are required?




Sorry for replying to myself, but I just stumbled on a possible
solution: using the typical
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?