Search edit field

[jzhs]

Using any recent DrRacket and Win10.

Type C-f to bring up search/replace. In either edit field type PgDown.

Strange dialog and command line window appears. I think the bad input should just be ignored.

Error message says "scroll-line-location method of text%: expected argument of type ; given: -1"

[gus-massa]

I can't reproduce this in DrRacket 8.0, 64bits, CS and BC, and It looks more like a problem in DrRacket, than a problem that depends on the exact version of Windows. (I may be wrong, sometimes there are unexpected interactions...)

Exactly which version of DrRacket are you using?

[sorawee]

I can reproduce the problem on Mac, Racket v8.0.0.13 [cs]. On Mac, PgDown is fn + down.

Here's the full error message:

scroll-line-location method of text%: expected argument of type <exact-nonnegative-integer>; given: -1
  context...:
   /Users/sorawee/projects/racket/extra-pkgs/gui/gui-lib/mred/private/wxme/text.rkt:3543:2: scroll-line-location method in text%
   /Users/sorawee/projects/racket/extra-pkgs/gui/gui-lib/mred/private/wxme/text.rkt:1052:2: move-position method in text%
   /Users/sorawee/projects/racket/extra-pkgs/gui/gui-lib/mred/private/wxme/text.rkt:5942:21: send-arg3758
   /Users/sorawee/projects/racket/extra-pkgs/gui/gui-lib/mred/private/wxme/keymap.rkt:739:2: call-function method in keymap%
   /Users/sorawee/projects/racket/extra-pkgs/gui/gui-lib/mred/private/wxme/keymap.rkt:511:2: chain-handle-key-event method in keymap%
   [repeats 2 more times]
   /Users/sorawee/projects/racket/extra-pkgs/gui/gui-lib/mred/private/wxme/keymap.rkt:462:2: handle-key-event method in keymap%
   /Users/sorawee/projects/racket/extra-pkgs/gui/gui-lib/mred/private/wxme/editor.rkt:215:2: on-local-char method in editor%
   /Users/sorawee/projects/racket/extra-pkgs/gui/gui-lib/mred/private/wxme/editor-canvas.rkt:504:2: on-char method in editor-canvas%
   /Users/sorawee/projects/racket/racket/collects/racket/private/more-scheme.rkt:148:2: call-with-break-parameterization
   /Users/sorawee/projects/racket/racket/collects/ffi/unsafe/atomic.rkt:73:13
   /Users/sorawee/projects/racket/extra-pkgs/gui/gui-lib/mred/private/wx/cocoa/window.rkt:890:4: dispatch-on-char method in window%
   /Users/sorawee/projects/racket/extra-pkgs/gui/gui-lib/mred/private/wx/common/queue.rkt:435:6
   /Users/sorawee/projects/racket/extra-pkgs/gui/gui-lib/mred/private/wx/common/queue.rkt:486:32
   /Users/sorawee/projects/racket/extra-pkgs/gui/gui-lib/mred/private/wx/common/queue.rkt:634:3

[gus-massa]

It's very interesting. I have a dedicated key for PgDown in my keyboard. Perhaps it's important.

Can someone else with other keyboards models try to reproduce it?

[Metaxal]

FWIW, I cannot reproduce the bug on Linux, Racket v8.9.0.4, with a dedicated PgDown key.

[rfindler]

I'm not able to reproduce this one either, but I do see one place where there is a sub1 that's not guarded to be positive. @sorawee : if you make this change, does the problem go away?

diff --git a/gui-lib/mred/private/wxme/text.rkt b/gui-lib/mred/private/wxme/text.rkt
index 87367db1..ee96fe09 100644
--- a/gui-lib/mred/private/wxme/text.rkt
+++ b/gui-lib/mred/private/wxme/text.rkt
@@ -1234,7 +1234,7 @@
                                                             (let* ([newtop (find-scroll-line (+ vy scroll-height))]
                                                                    [y (scroll-line-location (+ newtop 1))]
                                                                    [newtop (if (y . > . (+ vy scroll-height))
-                                                                               (sub1 newtop)
+                                                                               (max 0 (sub1 newtop))
                                                                                newtop)]
                                                                    [y (scroll-line-location newtop)])
                                                               ;; y is the new top location

[sorawee]

Yes! With the fix, the error no longer occurs.

FWIW, to reproduce the issue, you need to make sure that org.racket-lang.prefs.rktd doesn't have these entries:

plt:framework-pref:framework:replace-visible?
plt:framework-pref:framework:search-string
plt:framework-pref:framework:replace-string

If these entries already exist, then the bug can't be reproduced.

While we are at it, let me report a related issue (I can also make a new issue if you prefer). If these entries do not exist, the UI will look weird.

Compare this against when these entries exist:

[rfindler]

Thanks!

As for the edits to the preferences, that's not enough for me to trigger the bad behavior that you report. That bad behavior is familiar to me, however, as the code that adjusts the size of the canvas containing the editor that has the search string can get into a bad state where it doesn't update itself to be big enough. It has been problematic for a long time. If there is something more you can find to help me trigger the bad state reliably, that'd be really great.

[rfindler]

Oh, and I should add that the pattern I've seen with the bad sizing for that canvas is that something changes while the canvas is not visible and that change should cause the canvas to resize. Then, when it is made visible again, it is the wrong size. So maybe something along those lines happened for you in this case.