Single-line TextEditor incorrect behavior with scroll wheel


When a single-line TextEditor component is placed into edit mode in an enclosing ViewPort, the ViewPort can only be scrolled horizontally when the cursor is actually inside the TextEditor control.

This behavior can be seen in the IntroJucer: Click to put a Project Settings TextEdit control into edit mode and then scroll. The result will be that the ViewPort scrolls once, but stops responding to the mouse wheel (because the first scrolling action causes the editor control to move relative to the mouse).


Single line texteditors don’t use the scroll wheel at all, do they?


They should ignore the scroll wheel and pass it up to the parent hierarchy. But try what I said and observe.


Did you try it?

No, neither single line TextEditor or Label in edit mode (which I think just uses a single line TextEditor) should use the scroll wheel. But they should also not capture the message.

If you try it, you will see that the single line TextEditor correctly scrolls the enclosing ViewPort when the mousewheel happens while the cursor is inside a TextEditor in edit mode. But right after it scrolls once, it stops working (because the TextEditor has now moved from being under the mouse).

This is an inconvenience in IntroJucer because after you change an “Export Targets” edit box setting, you have to press escape or click outside of the label in order to use the mousewheel to scroll the enclosing view:


But more importantly it will be an inconvenience for any JUCE dialog that has an enclosing ViewPort with a bunch of single line TextEditor (or Label).


Am I the only person who can reproduce this?


I agree with TheVinn, and I can reproduce what he’s experiencing.

For working with intuition, scrolling should happen where there’s scrolling available, in the region where the mouse is positioned. The TextEditor, and editable Label, shouldn’t take hold of the scroll wheel messages. If they do receive them, they should pass the scrolling messages up to the parent to let it decide what to do with them, especially since they’ve no true use for them.

A non-JUCE example: I’m able to type in this text-box that created this post when it’s in focus, and scroll up and down the entire webpage, so long as my mouse cursor is not in the lower topic-review section. If that happens, I am able to scroll that section instead of the webpage itself.


What’s actually happening here is that when you click a Label, it shows the text editor modally, so while the editor is modal, events are being blocked from reaching the other non-modal components, and that includes stopping wheel messages from hitting the main viewport.

I don’t think that’s incorrect, it’s just due to the fact that these are Labels rather than normal TextEditors.


Yes, but the issue Vincent is reporting is not the modality of the editor. Scrollwheel acts on the component that’s under the cursor, so it doesn’t care about the modal state (unlike a mouse click or mouseEnter etc).
So since the intend when scrolling the wheel is not behaving like the other mouse message, the component shouldn’t care about the modal state in that case.
Try this in a browser with a form with multiple text input (like the reply part of this forum), they don’t check the focused control for allowing scrolling.
This behaviour is common in app but missing in Juce (unless you write hacks to fix it in your application). I think it should be the default.


Well, again, I really think that if you want that functionality you need a TextEditor, not a Label.

The label class was originally designed for things that were mostly read-only, but which could be put into a modal edit-mode by clicking or double-clicking them. They were never meant to be live all the time, and the modal nature of editing them was deliberate.

I think the confusion/mistake here is that I used Labels in the property editors, when perhaps TextEditors would have been a better choice…


This is still a problem - JUCE doesn’t behave like any other Windows / OSX application in this regard.