Bwidget Source Code
View Ticket
Not logged in
Bounty program for improvements to Tcl and certain Tcl packages.
Tcl 2019 Conference, Houston/TX, US, Nov 4-8
Send your abstracts to [email protected]
or submit via the online form by Sep 9.
Ticket UUID: 45668dbdf0a50fd901270781643f771c23811dd7
Title: ScrollableFrame fails with too many widgets
Type: Bug Version: 1.9.10
Submitter: anonymous Created on: 2017-10-22 09:22:24
Subsystem: bwidget Assigned To: nobody
Priority: 5 Medium Severity: Minor
Status: Open Last Modified: 2017-10-31 01:14:45
Resolution: None Closed By: nobody
    Closed on:

If a ScrollableFrame contains too many widgets, it does not display / scroll them correctly anymore. Either the frame does not scroll below a certain point (even if there would be more widgets), or - sometimes - widgets that should be placed towards the bottom of the frame, show up at the top.

This script demonstrates the issue:

#!/usr/bin/env tclsh
package require Tk 8.6
package require BWidget 1.9.7

set widgetCount 200
set widgetHeight 20

# UI #
ScrollableFrame .sf 
grid .sf -column 0 -row 0 -sticky nsew
grid columnconfigure . 0 -weight 1

# Scroll bindings #
bind . <Button-4> [list .sf yview scroll -1 unit]
bind . <Button-5> [list .sf yview scroll 1 unit]
bind . <u> [list .sf yview scroll -1 unit]
bind . <d> [list .sf yview scroll 1 unit]

grid rowconfigure . 0 -weight 1

# Create widgets #
for {set i 1} {$i <= $widgetCount} {incr i} {
    grid [label [.sf getframe].$i -text $i -height $widgetHeight]

(run and try to scroll to label #200)


  • If the problem does not reproduce, try increasing the 'widgetHeight' and / or 'widgetCount' vars.
  • The key factor seems to be the total height of widgets in the frame and not their number. i.e. the same effect could be reproduced with less widgets, if they are higher.

User Comments: kjnash added on 2017-10-31 01:14:45:
I've run into this limit too, at around 32k pixels.  I believe it is a limitation of Tk, and is beyond the scope of BWidget.  I reported it on the Tk bug tracker.

anonymous (claiming to be Simon Bachmann) added on 2017-10-23 20:37:59:
I kinda suspected it's some internal limitation.

The limit seems to be more like 33600 points (approx).

BTW: [winfo] returns the correct size even for values far above 65536, but after about 33600 I cannot scroll all the way down anymore.

oehhar added on 2017-10-23 15:51:57:

Hi Simon,

thank you for the report.

I suppose, you hit an internal limitation of the used canvas widget, which can not exceed 65536*65536 (when I remember right) points.

What does

% winfo height [.sf getframe]
return for you ?

If this is larger, it does not work, right ?

So, I am sorry, I suppose, this is not fixable.

There are some widgets which do not use a canvas as scrolling base which allow larger scrolling regions.

Others may comment to.

Thank you, Harald