Maximum canvas% scroll-range of 1,000,000 pixels?

[jjsimpso]

I see the following contract violation in my program when the scroll range exceeds 1,000,000. I'm providing pixels as the units to the set-scroll-range function. Assuming using pixels is correct here, I propose 1,000,000 pixels is too small for a maximum range since I have run into the limit displaying a text file with about 30,000 lines.

set-scroll-range in canvas%: contract violation expected: (integer-in 0 1000000) given: 1130504.0 Context (plain; to see better errortrace context, re-run with C-u prefix): /usr/local/racket/share/pkgs/gui-lib/mred/private/lock.rkt:43:38 /usr/local/racket/collects/ffi/unsafe/atomic.rkt:73:13 /home/jonathan/git/molasses/src/test/newcanvas.rkt:265:4 update-scrollbars /usr/local/racket/collects/racket/private/more-scheme.rkt:148:2 call-with-break-parameterization /usr/local/racket/share/pkgs/gui-lib/mred/private/lock.rkt:43:38 /usr/local/racket/collects/ffi/unsafe/atomic.rkt:73:13 /usr/local/racket/share/pkgs/gui-lib/mred/private/wx/common/queue.rkt:435:6 /usr/local/racket/share/pkgs/gui-lib/mred/private/wx/common/queue.rkt:460:2 yield

[spdegabrielle]

I’m guessing this is a significant piece of work? You would need to build tests in addition to making the change. 30,000 seems very large for a single file. Text editor applications normally implement their own strategies to manage large files, as most gui toolkits do not offer this as part of core functionality.

I believe pages is how emacs handles large files. I found this http://www.finseth.com/craft/#c4

[jjsimpso]

I expect that the issue here is just an arbitrary limit added in the contract for set-scroll-range, but I could be wrong if the limit is due to an underlying limit in the GUI toolkit. The contract in question is checking for dimension-integer?.

My app is actually using a subclass of canvas% which is handling the data, but my canvas does need a way to communicate the size of the virtual canvas to the scroll bar widgets provided by canvas%.

[jryans]

Here's a commit from 2013 when these limits were last tweaked: https://github.com/racket/gui/commit/4ad479277821641fb39b8ae8e9c20a76b36e9e9a

The commit message there suggests canvases larger than 32k in a dimension may struggle on some platforms.

[jjsimpso]

@jryans, thanks for pointing me to that commit. One thing I noticed is that the range for most things was increased, but the range for scroll bars was actually decreased from 10,000,000 to GAUGE_MAX, which is only 1,000,000.

In my case the scroll range is just an abstract value representing the size of a virtual canvas. It isn't tied to anything in the underlying GUI toolkit, so I don't see any reason to limit it.

I suppose I do have some other options, but they have drawbacks/complications.

1) I could change my scroll range units to something else besides pixels, like lines. This would require a bit of work on my end, but perhaps it is worth doing anyway. I haven't investigated yet.

2) Potentially I could override the set-scroll-range method in canvas%, but since this is implemented in terms of the wx layer below that, I may have to re-implement all of the scroll bar functions in my canvas.

[racket-discourse-github-bot]

This issue has been mentioned on Racket Discourse. There might be relevant details there:

https://racket.discourse.group/t/scrollbar-problems-on-windows/3314/1